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1 Introduction 

This document addresses the functional requirements spelled out in Contract [1] Section 

6.111- 6 and its subsections, as well as applicable requirements from Contract [1] Section 

6.111- 3. 


1.1 Purpose 

This specification establishes the performance, design, development, and test 
specifications for the OBFTP (On-Board Fare Transaction Processor) at an (FDR) Final 
Design Review level. 


1.2 Scope 

The scope of this document is limited to the FDR-level functionality design of the OBFTP. 
The OBFTP will be installed in buses. It performs all fare collection functionality. It 
interfaces with the Driver Display Unit (DDU) to provide feedback of transactions to the 
Operator and to accept input from the Operator. 

Note: This document covers the On-Board FTP device. Other FTP devices are 
covered in other DR documents as follows: 

SEA-00041 Portable Fare Transaction Processor (DR 105) [12] 

SEA-01051 Portable Fare Transaction Processor (DR 105A) - Hardware 
Specification [20] 

SEA-01052 Portable Fare Transaction Processor (DR 105B) - Functional 
Specification [21] 

SEA-00042 Stand Alone Fare Transaction Processor (DR 106) [13] 

SEA-01055 Stand Alone Fare Transaction Processor (DR 106A) - 

Hardware Specification [22] 

SEA-01056 Stand Alone Fare Transaction Processor (DR 106B) - 

Functional Specification [23] 

The DDU provides the Operator display and keypad input for the control 
aspect of the OBFTP and is referenced in the following documents: 

SEA-00039 Driver Display Unit (DR 103) [14] 

SEA-01047 Driver Display Unit (DR 103A) - Hardware Specification [18] 
SEA-01048 Driver Display Unit (DR 103B) - Functional Specification [19] 


ERG Confidential © ERG 2010 
To be disclosed only to Agency personnel who 
have a need to know 


SEA-01050 

Revision 13.0/Feb 22, 2010 




This section contains a list of acronyms, abbreviations, and terms used in this document. 

Acronyms and Abbreviations 

Table 1 is a list of acronyms and abbreviations that are specific to ERG. Industry 
standard acronyms and abbreviations are not covered in this table. 

Table 1: Acronyms and Abbreviations 

Acronym or 
Abbreviation 

Definition 

AFC 

Automated Fare Collection 

CD 

Configuration Data 

CSC 

Contactless Smart Card 

DAC 

Data Acquisition Computer 

DDU 

Driver Display Unit 

ESN 

Electronic Serial Number 

FIM 

Full Integration Mode 

FTP 

Fare Transaction Processor 

IPnn 

Ingress Protection rating, where nn indicates a numeral 

LIM 

Limited Integration Mode 

MCR 

Multiple Protocol Card Reader 

MOHBF 

Mean Operating Hours Between Failures 

MOS 

Modular Operating System 

OB FTP 

On Board Fare Transaction Processor 

PDR 

Preliminary Design Review 

RFA 

Ride-Free Area 

RS (xxx) 

Report Server 

TSP 

Transit Signal Priority 

UD 

Usage Data 

VLU 

Vehicle Logic Unit 

WDOLS 

Wireless Data On/Off Loading System 
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1.4 References 

The following materials are to be used in conjunction with or are referenced by this 
document. 

[1] Contract 229944 (April 29, 2003) as amended and conformed 
Division III: Equipment Specifications 

[2] SEA-00105 
System Architecture 

[3] SEA-00090 
Business Architecture 

[4] SEA-00101 

Electromagnetic Compatibility Plan (CDRL 32) 

[5] SEA-00032 
Communications Network (DR 7) 

[6] SEA-00739 

ERGRFI 00179 FTP memory capacity 

[7] SEA-00415 

ERGRFI 00082 Key stamping 

[8] SEA-00615 

ERGRFI 00151 FTP customized colors 

[9] SEA-00411 

ERGRFI 00077 Stainless steel finish 

[10] SEA-00412 

ERGRFI 00078 Clear liquids 

[11] SEA-00416 

ERGRFI 00083 LonWorks Port 

[12] SEA-00041 

Portable Fare Transaction Processor (DR 105) 

[13] SEA-00042 

Stand Alone Fare Transaction Processor (DR 106) 

[14] SEA-00039 

Driver Display Unit (DR 103) 

[15] SEA-00104 

System Backup and Recovery Plan (CDRL 5) 

[16] SEA-00430 

ERGRFI 00086 Origin & Destination in UD 

[17] SEA-01199 

Overall Inspection and Test Plan (CDRL 23) 

[18] SEA-01047 

Driver Display Unit (DR 103A) - Flardware Specification 

[19] SEA-01048 

Driver Display Unit (DR 103B) - Functional Specification 
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[20] SEA-01051 

Portable Fare Transaction Processor (DR 105A) - Hardware Specification 

[21] SEA-01052 

Portable Fare Transaction Processor (DR 105B) - Functional Specification 

[22] SEA-01055 

Stand Alone Fare Transaction Processor (DR 106A) - Hardware Specification 

[23] SEA-01056 

Stand Alone Fare Transaction Processor (DR 106B) - Functional Specification 

[24] DPG-00058 

Device Discovery Specification 

[25] DPG-00059 

Device Extensible Protocol Specification 

[26] DPG-00299 

DHMI API Reference Manual 

[27] SEA-01285 

DDU and OBFTP Site Managers - Meeting Notes - 2004-10-05 

[28] SEA-01286 

DDU and OBFTP Community Transit - Meeting Notes - 2004-10-06 

[29] SEA-01287 

DDU and OBFTP King County Metro - Meeting Notes - 2004-10-07 

[30] SEA-01288 

DDU and OBFTP Kitsap Transit - Meeting Notes - 2004-10-07 

[31] SEA-01302 

King County Metro - Meeting Notes - 2004-10-12 

[32] SEA-01319 

DDU and OBFTP King County Metro - Meeting Notes - 2004-10-28 

[33] SEA-01322 

DDU and OBFTP Sound Transit - Meeting Notes - 2004-10-29 

[34] SEA-01324 

DDU and OBFTP Kitsap Transit - Meeting Notes - 2004-10-18 

[35] SEA-01325 

DDU and OBFTP Everett Transit - Meeting Notes - 2004-10-18 

[36] SEA-01326 

DDU and OBFTP Community Transit - Meeting Notes - 2004-10-20 

[37] SEA-01305 

CT DDU Operations Screen-flows 

[38] SEA-01314 

KCM DDU Operations Screen-flows 

[39] SEA-01469 

ET DDU Operations Screen-flows 

[40] SEA-01316 

KT DDU Operations Screen-flows 

[41] SEA-01317 

PT DDU Operations Screen-flows 
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[42] SEA-01429 

DDU/OBFTP Screen-flow Regional Decisions 

[43] SEA-01516 

DDU/OBFTP Design Finalization Workshop Notes - 2005-01 -11 

[44] SEA-01340 

Consolidated RFCS design issue list 

[45] SEA-01092 

Fare Calculation Overview 

[46] SEA-00100 

System Security Plan (CDRL 31) 

[47] SEA-01355 

Card Procurement, Distribution, and Management (DR 3 & DR 4) 
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2 Hardware Design (Refer to SEA-01049 
(DR102A)) 

This section is intentionally left blank. 
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3 Functionality Design 


3.1 Introduction 

The OBFTP application is designed to perform the following basic functions: 

• Perform an OBFTP system self-test at start-up to ensure that all subsystems are 
functioning correctly and report any faults encountered (where possible). 

• Allow authorized logon for operation and diagnostics. 

• Maintain time and date information. 

• Accept operational commands via the DAC. 

• Download and store CD (configuration data) from the DAC. 

• Process transactions in accordance with business rules and CD. 

• Store details of transactions and events as UD (usage data). 

• Store non-fare card ridership events as UD. 

• Upload UD to the DAC. 

• Display messages to the operator and to cardholders. 

• Display status indications to the operator and to cardholders. 

• Provide audio feedback to the operator and to cardholders. 

• Monitor memory usage and prevent further transactions if memory is full. 

• Monitor device status and attempt to log and report on faults. 

• Manage dialogs with the DDU. 


3.2 Operational Architecture (DR 102.06) 

The OBFTP has a flexible architecture and is supplied for installation onto buses. The 
OBFTP is designed to integrate seamlessly with either Limited Integration Mode (LIM) or 
Full Integration Mode (FIM) operation, connecting with all on-board systems via a 
10/IOOBaseT Ethernet 802.3 LAN connection. 

The OBFTP has no keypad for operator or cardholder input. A contactless smart card 
reader/writer enables the OBFTP to act autonomously to process fare card payment 
transactions, according to fare tables and other configuration data downloaded from the 
Central System. The DDU will allow the operator to interface with the OBFTP to log on, 
log off, and perform specific fare transactions, such as application upgrades or 
transaction reversals. 

All cardholder fare transactions require the presentation of a cardholder fare card to the 
OBFTP target. The OBFTP subsequently computes the required fare. For all 
transactions, the validity of the card is first checked and, if valid, payment is automatically 
processed. The OBFTP will also store non-fare-card ridership events as transactions. 

The result of a successful transaction is displayed on the LCD along with a green LED 
and audible confirmation. If the fare card is invalid, an Invalid Card message and a red 
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LED are displayed and an audible alarm is sounded. All data concerning the transaction 
is displayed on the LCD during the transaction. When the fare is charged, the fare card 
value is adjusted and the result of the adjustment is displayed. The fare basis used to 
calculate the fare is also displayed. 

During operation, the OBFTP generates UD, logging all transactions, operator logon, 
logoff, and OBFTP events. This data is captured and held until an upload to the DAC via 
the Wireless Data On/Off Loading System (WDOLS). When a connection is established 
with the DAC, the time of day and date are synchronized and any CD, fare tables, and 
application updates are also downloaded as required. If UD memory becomes full, the 
OBFTP will go Out of Service until UD is uploaded to a DAC. 


3.3 Device Role 

The OBFTP provides the following major functionality: 

• An OBFTP display to provide a payment acceptance peripheral for the automatic 
processing of fare cards and feedback on the outcome of those transactions. 

• A communications interface to a DAC (via the WDOLS) to transfer CD, UD, and 
messages. An alternate data path via a diagnostic computer connected to the 
diagnostic port provides this functionality in the case of failure of the primary 
communications interface. 

• Connect to the Vehicle Logic Unit (VLU). The OBFTP exchanges data with the VLU 
via the Driver Display Unit (DDU), specifically using the public data area provided by 
the DDU application for the purposes of sharing information between various on-board 
devices or subsystems. Refer to SEA-01048 Driver 
Functional Specification [19] for more detail. 

Note: The DDU is designed to operate even when the 
and therefore it does not rely on the OBFTP 
applications or configuration data. 


3.4 External Interface Functionality 

The OBFTP communicates with the following external devices (shown in Figure 1): 

• DAC (via WDOLS) 

• DDU (using Ethernet) 

• Diagnostic port (using RS232) 

• Smart card (contactless) 

• VLU (using Ethernet via DDU) 


Display Unit (DR 103B) - 

OBFTP is not serviceable, 
for the transport of DDU 
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11 


Figure 1:OBFTP Interfaces 

Note: The OBFTP exchanges data with the VLU via the DDU, specifically using 
the public data area provided by the DDU application. Refer also to 
section 3.3. 

Note: The VLU is introduced at Full Integration Mode (FIM). 

3.4.1 DAC Interface 

The OBFTP communicates with the DAC to transfer: 

. UD 
. CD 

• Application and other operational files and data 

• Commands 

• Messages 

The primary interface is via the on-board Ethernet network and wireless communications 
network incorporating the on-board WDOLS and access points located at the depots. 

The secondary interface is via the diagnostics interface described in section 3.4.3. 

The DAC interface specification is detailed in DPG-00058 Device Discovery Specification 
[24] and DPG-00059 Device Extensible Protocol Specification [25]. 

3.4.2 DDU Interface 

The OBFTP communicates with the DDU for display of fare collection information to the 
operator and for input of operator commands entered on the DDU keyboard. 
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The OBFTP and DDU communicate via the on-board Ethernet network. 


Note: The Automated Fare Collection (AFC) application is the application 
running on the DDU that communicates with the fare collection application 
running on the OBFTP. 

The DDU interface specification is detailed in DPG-00299 DHMI API Reference Manual 
[26], It is also discussed in SEA-01048 Driver Display Unit (DR 103B) - Functional 
Specification [19], 

3.4.3 Diagnostics Interface 

The OBFTP has an RS232 serial diagnostic port. The port is accessible externally to the 
device. It serves the purposes of data backup as described in section 3.7 and OBFTP 
maintenance as described in section 3.10.3.17. 

The DAC interface specification is detailed in DPG-00058 Device Discovery Specification 
[24] and DPG-00059 Device Extensible Protocol Specification [25]. 


3.4.4 Contactless Smart Card 

The OBFTP communicates with contactless fare cards via the Contactless Smart Card 
Interface. Communication can involve reading from and writing to the fare card. The 
interface supports communication with cardholder and operator smart cards. Operator 
smart cards support multiple operator roles on a single card. Refer to sections 2.3.3 and 
3.6.1.2 for more detail. 


3.4.5 VLU Interface 

The OBFTP will communicate with a future VLU. 

[The OBFTP will exchange data with the VLU via the DDU, specifically, using the public 
data area provided by the DDU application , when operating in Full Integration Made 
(FIM) . 

ERG proposes that a VLU- FIM application on the DDU will provide an interface to the 
VLU. It will also access the public data area on the DDU to provide the OBFTP (and/or 
other third-party equipment) with information (e.g., GPS iocaa -emirip information) or to 

obtain information from the OBFTP (e.g., logon information). Commented [dl]: change order #32. 

Refer also to SEA-01048 Driver Display Unit (DR 103B) - Functional Specification [19] 
for more detail regarding the DDU and public data areas and sharing of information. 


3.5 Operating System and Base Functionality 

The ERG MOS (Modular Operating System) in the OBFTP provides a multitasking, real¬ 
time kernel, and the fare transaction processing application that implements the 
functionality of the OBFTP. Because it is modular, MOS allows easy maintenance and 
upgrades of the OS and application. Built-in start-up self-tests perform hardware 
verification on power-up and provide notification of any faults found. The ERG MOS 
provides the following: 

• Start-up self tests 

• Operating kernel 
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• TCP/IP stack 

• Fare Transaction Processing Application 

• File systems for the flash, SRAM and FRAM memory systems 

• Application upgrades 


3.5.1 Start-up and Self-Tests 

The operating system performs a self-test on start-up to ensure that all OBFTP hardware 
is operating normally. Test results are displayed in real time and logged where applicable 
for subsequent access. The self-test does not require the connection of any external 
equipment. 


3.5.2 Kernel 

The kernel allows multiple tasks to run concurrently in real time, prioritizing tasks to allow 
higher priority tasks to take precedence over lower priority tasks. This allows real-time 
responses to external sources such as keypad entry communications from the DDU. 
Provision is made for the connection of a diagnostic interface using the RS232 port or 
Telnet though the LAN interface and TCP/IP stack. 


3.5.3 TCP/IP Stack 

The TCP/IP stack addresses the following standard Internet protocols: 
. IP 
• ICMP 


. DHCP (client only) 

. TCP 

• UDP 

The TCP/IP stack provides a standard Berkley Socket API (BSD 4.3) for application 
programs and the following optional link layer operators: 

• Ethernet 
. PPP 

• SLIP 

The TCP/IP stack provides the following optional physical layer: 

• RS232 serial 

The TCP/IP stack provides the following application layer services: 

• Telnet (for Task Monitor only) 

. TFTP 
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3.5.4 File Systems 

The operating system provides: 

• A flash filing system for the persistent storage of CD, fare tables, and UD in flash 
memory 

• A RAM filing system for the persistent storage of device configuration data in battery 
backed SRAM 

• A FRAM filing system for the persistent storage of audit registers and manufacturing 
data. 


3.5.5 Software Installation 

A base version of the OBFTP application is loaded during manufacture to allow 
subsequent application upgrade during OBFTP installation. Software installation and 
upgrade may occur through one of the following means: 

• Upgrade of modules via CD and file system 

This uses the primary data path (i.e. via the WDOLS) and is applicable to application 
upgrades only, as the base application loaded during manufacture is required to 
support the transfer. Connection to the WDOLS is made directly by the OBFTP. 

• Upgrade of modules via the alternate data path 

This uses the diagnostic port as an alternate data path in a similar way to the primary 
data path described above. 


3.6 Device Management 


3.6.1 Security 

OBFTP security provides functions to authenticate and/or uniquely sign the following: 

• Communication with the CSC 

• Communication with DAC devices 

• UD 

. CD 

Note: The OBFTP will exchange data with the VLU via the DDU, so it will not 
explicitly authenticate communications with the VLU. As outlined in section 
3.4.5, an application on the DDU will interface to the VLU; this application 
will be certified and authenticated as part of secure application download 
to the DDU. 

Refer also to SEA-01048 Driver Display Unit (DR 103B) - Functional Specification [19] 

for more detail regarding the DDU and public data areas and sharing of information, as 

well as third-party application certification. 
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3.6.1.1 Secure Access Module (Hardware SAM) 

The OBFTP SAM provides stronger security based in hardware, as opposed to the SSM 
(Software Security Module). The SAM supports the following: 

• Security keys and/or security software may reside in a SAM to provide stronger 
security than an SSM. 

• Security keys held in the SAM may be updated, but they are not accessible. 

3.6.1.2 Contactless Smart Card Data 

The OBFTP application has measures in place to ensure that data on the CSC 
(contactless smart card) is valid and consistent, in the event that the CSC is removed 
from the CSC interface prematurely. These are described below. CSC data 
communications and data security are compliant with ISO 14443 part 4. 

The smart card contains two copies of each file. These are designated the current 
version and the new version. During writing to the smart card, the new version of the file 
is updated. The last operation performed on the card is to change the new version to be 
the current version, ensuring data consistency. 

3.6.2 Timekeeping 

The OBFTP provides a real-time clock (RTC) to maintain date and time. Where 
applicable, the RTC supports daylight saving time under control of CD. The RTC time 
and date are updated each time the OBFTP connects to a DAC. 

3.6.3 Data Integrity 

Power failures, power fluctuations, or power spikes do not cause damage to or loss of 
UD, CD, and audit register data stored within OBFTP memory systems. 

Security measures are in place to ensure that data is not duplicated, lost, or corrupted. 


3.6.4 Configuration Data 

The OBFTP is able to download CD from the DAC automatically, carrying out validation 
of the received data using the security subsystem. Two CD sets can be stored in the 
device simultaneously, i.e., the current set and a set for future activation at a 
predetermined time. CD adjusts the operational characteristics of the device. Examples 


• Time and date accuracy (synchronizes with the back office) 

• Daylight saving time adjustments 

• Operating system upgrades 

• Application upgrades 

• Device operator upgrades 

• Fare tables 

• Actionlists 


• Security keys and access control (e.g., username/password) upgrades 
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• Device Control Parameters 

• Hotlists 

New CD sets are checked for corruption and consistency before the previous CD set is 

replaced. 

Note: For some configuration data files it is not necessary to store current and 
future files as described above. For example, actionlist files, where the 
new file replaces the current file, as it contains the latest information and 
is always ‘active’. 


3.6.5 Usage Data 

UD is stored and uploaded to the DAC automatically (via WDOLS) at end of shift when 
the bus returns to the depot. Uploaded UD is checked and verified by the DAC. UD is not 
cleared from the OBFTP until the DAC has verified successful data transfer. If a failure 
occurs during UD upload, the UD is retained until successful transfer has been 
confirmed. The OBFTP may archive or delete stored UD as appropriate after a 
successful upload dependent on requirements held in CD. 

UD details the operation of the device and includes details such as: 

• Cardholder transaction details 

• Device subsystem events and faults 

• Operator logon/logoff 

• Operator initiated events (non-fare-card ridership events) 


3.6.6 LAN Messaging 

The OBFTP is able to upload and download data to and from the DAC as instructions or 
messages for processing. Typical data is CD, UD, and control and status messaging. 

3.6.7 Power Monitoring and Control 

Power supplies of 5 VDC and 12 VDC are derived internally from the regulated 12 VDC - 
24 VDC input. The DC input is monitored to signal the CPU when a power failure is 
imminent, in order for the CPU to perform an orderly shutdown of the OBFTP. 

In the event that power failures, power fluctuations, or power spikes cause OBFTP 
shutdowns, the device is designed to restart automatically when power is restored. No 
damage to data stored within OBFTP memory systems occurs, thus UD, CD, fare tables 
and audit registers are maintained intact. 


3.6.8 Application Upgrade 

A new OBFTP is shipped with a base application allowing the download of a current 
RFCS application. After download of the RFCS application, the OBFTP may be 
configured with CD, fare tables, and other applicable operational data as required. 

The OBFTP automatically downloads new applications when required, automatically and 
without operator interaction. The OBFTP ensures that no UD is lost as a result of such an 
upgrade. 
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3.6.9 Maintenance Mode 

Maintenance mode allows self-tests to be performed at times other than start-up. 
Maintenance mode allows interactive tests to be run to determine if the OBFTP is 
operating correctly. Maintenance mode is entered on presentation of a valid Maintenance 
mode card by maintenance personnel. 


Table 3: Mode Changes 



3.7 OBFTP Backup System 

The backup system is primarily used to upload UD from the OBFTP in the event of a 
serious device or primary data path (WLAN) interface failure preventing normal upload. 
The alternate data path (serial diagnostics port) allows manual upload of UD to, and 
download of CD from, a portable diagnostic PC provided that there is not a failure 
affecting this interface, such as a CPU failure. 

The PC used for the capture of UD by this means is capable of connecting to a DAC or 
Central System for the transfer of captured UD. 

See SEA-00104 System Backup and Recovery Plan (CDRL 5) [15] for details regarding 
data backup and recovery. 

3.8 Performance Characteristics 

This section describes the performance characteristics of the OBFTP. 

3.8.1 Transaction Processing Times 

The transaction processing time for the OBFTP is shown in Table 4. Note that the 
transaction time includes: 

• Initialization 

• Authentication and other security processes 

• Data exchange (read and write) 

• Computation of fare, including applicable incentives or discounts 

• Initiation of display of results on the OBFTP and other displays 


Table 4: OBFTP Transaction Processing Time 
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Note: The display of transaction information on the DDU is somewhat dependent 
on other activities on the DDU and the on-board Ethernet network that 
may be occurring at the same time; it is expected that the display at the 
DDU should be completed within a total of 500 msec (including the 
network transmission and transaction processing times). 


3.8.2 Cardholder Throughput 

The OBFTP supports a throughput of a minimum of 30 transactions per minute. For this 
throughput rate to be achieved, it is assumed that: 

• Cardholders are familiar with the operation of the device 

• That their fare cards are valid 

• That their fare cards have sufficient stored funds or passes as applicable for the 
transaction 


3.9 User Interface 

The Ul (user interface) refers to the method used by cardholders and operators to enter 
information and to obtain status and feedback from the OBFTP. The Ul comprises the 
LCD, text and graphical displays, LED indicators, the audio interface, and the CSC 
reader/writer. All of these interfaces are designed for ease of use in a mobile 
environment. All functions and operations enabled by the Ul are intuitive and require the 
minimum of operations to achieve the desired outcome. The LCD and LEDs are clearly 
visible in all lighting conditions and audio tones are of sufficient volume to be clearly 
heard in a mobile environment. 


3.9.1 General 

In addition to the LCD, LED indicators, and audio interface for feedback to cardholders, 
the OBFTP also provides an interface to drivers. 

The OBFTP sends information for drivers to the DDU for display in the AFC application 
window on the DDU. The AFC application on the DDU also passes driver hotkey presses 
to the OBFTP for processing. 

In the remainder of this document, the AFC application and the corresponding AFC 
application window on the DDU will be referred to simply as ‘the DDU’. For detail on the 
AFC application on the DDU, use of templates, and the interface between the OBFTP 
and DDU refer to SEA-01048 Driver Display Unit (DR 103B) - Functional Specification 

[19] 


3.9.1.1 Status Indicators (LED) 

The three status indicator LEDs are used in conjunction with the OBFTP display when 
transaction results are displayed. Different color LEDs are used to indicate different 
transaction results as listed in Table 5. 


ERG Confidential © ERG 2010 
To be disclosed only to Agency personnel who 
have a need to know 


SEA-01050 

Revision 13.0/Feb 22, 2010 




Central Puget Sound 

Regional Fare Coordination System 


Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


Table 5: Cardholder Visual Status Indicator Matrix 


Condition 


Successful transaction 


Warning (such as low value purse) 

Incomplete or failed fare card read 

Unsuccessful transaction (for example, purse insutticient 

or blocked fare card) 


Indicator 


value, expired, 


Solid green 
Solid yellow 
Flashing red 
Solid red 


Speaker 

A speaker provides complimentary audio feedback to accompany the status indicators of 
the success or failure of fare card transactions. Different tones are used to indicate 
different transaction statuses as listed in Table 6 and further elaborated in Appendix B. 


Table 6: Cardholder Audio Status Indicator Matrix 


Condition 


Sound 


Successful transaction 


Warning (such as low value purse) 


Incomplete or failed fare card read 


Unsuccessful transaction (for example, purse insufficient value, expired, 
or blocked fare card) 


Attention (device mode change or prompt to cardholder) 


Indicators 
Indicator 4 


3.10 OBFTP Application 

This section describes the functional behavior of the OBFTP software. 

3.10.1 Software Diagram Symbols 

There are two types of diagrams that detail the functional screens and modes of the 
OBFTP. 

• Screen Flow diagrams - legend shown in Table 7 

• Mode diagrams - legend shown in Table 8 
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r "\ 

screen tag 

A screen to be shown on the OBFTP. The 
text within the symbol is always bold. 


A significant processing point or decision 
point in the flow as described by the text 
within the symbol. 

l^odenamej 

A separate mode that the OBFTP can 
enter as identified by the text within the 
symbol. 

Table 8: Mode Diagram Symbc 

O 

ils 

The currently active mode 

DAC Connection 

A mode that can be accessed from the 
currently active mode 


The OBFTP attempts to connect to the DAC over the WDOLS, whenever the device is 
off-shift (operator has logged off manually or been logged off automatically), and the 
vehicle is in range of an 802.11b WLAN access point. Communication between the 
OBFTP and the DAC occurs automatically, requiring no operator intervention. 
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3.10.3 OBFTP Operational Modes 

The OBFTP application supports the following operational modes: 

• Start-Up mode 

• Data Transfer mode 

• Out of Service/Logon mode 

• Out of Service/Fault mode 

• Out of Service/Memory Full mode [asynchronous] 

• On Shift mode 

• Select Route/Run mode 

• Select Trip mode 

• On Trip mode 

o Reverse Transaction mode 
o Group Transaction mode 
o' Select Fareset mode 
o Fare Override mode 

• Locked mode 

• End Shift mode 

• Training Functions 

• Maintenance mode 

• Supervisor mode 

• Device Configuration mode 

• Device Control mode 

• Shutdown mode 

Note: Modes shown indented are submodes of the parent mode above, and are 
submodes of On Trip mode. 

An overview of the OBFTP operational modes is shown in Figure 2. For clarity the 
submodes of On Trip mode are not shown; however, they are described in detail in 
subsections within section 3.10.3.10. 
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Figure 2: OBFTP Operational Modes Overview 
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Start-Up Mode 

This section describes those actions that the OBFTP is to take whenever it is powered up 
or reset. In this mode, the OBFTP initializes and tests both hardware and software 
subsystems. 



Required Off Less than CD 



Figure 3: Start-Up Mode 


3.10.3.2.1 Entry Conditions 

Start-Up mode is entered when the OBFTP is powered up or reset and the application 
begins operation. Powering the OBFTP involves the following event: 

• Ignition switch of the vehicle is turned to ON. 
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Regional Fare Coordination System 

3.10.3.2.2 Sequence of Events 



1. The OBFTP performs a set of basic system tests and ensures that all previously 
registered on-board devices are present. Refer to section 3.10.3.2.2.1. 

2. The OBFTP establishes communications with all other registered on-board devices, 
including the DDU. Refer to section 3.10.3.2.3. 

3. The OBFTP displays the Start-Up screen on the OBFTP display. Refer to the ‘OBFTP 
- Start-Up' screen in the screen-flow presentations in Appendix C for the proposed 
screen. Details displayed on the screen are: 




b. 

Device type 


c. 

Application version 


d. 

Application release date 


e. 

Device ESN (electronic serial number) 
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f. Device IP address 

4. The OBFTP sends the Start-Up screen details to the DDU. Refer to the ‘DDU - Start- 
Up’ screen in the screen-flow presentations in Appendix C for the proposed screen. 
Details displayed on the screen are: 

a. Project name 

b. Device type 

c. Application version 

d. Application release date 

e. Device ESN 

f. Initialization information 

g. Device IP address 

5. If the OBFTP has not yet been commissioned (installed), the OBFTP enters Device 
Configuration mode and performs the steps outlined in section 3.10.3.19. 

6. The OBFTP determines that it has valid application software with the correct 
version(s). This is achieved by verification of the Cyclic Redundancy Check (CRC) 
value(s). 

7. The OBFTP verifies the configuration parameters of the device, by comparing these 
details in the OBFTP with the details in the active cradle. 

8. The OBFTP will ensure the validity and completeness of CD. 

9. The OBFTP checks UD memory capacity and sends the Memory Almost Full screen 
to the DDU if memory usage is at a CD set threshold. Refer to the ‘OBFTP & DDU - 
OBFTP Memory Full' screen in the screen-flow presentations in Appendix C for the 
proposed screen(s). 

10. The OBFTP enters Out Of Service/Logon mode or previous operational mode, 
depending on the device logon status at the time. Refer to section 3.10.3.2. The 
OBFTP displays the Out of Service screen, and sends the Out of Service screen to 
the DDU. Refer to the ‘OBFTP & DDU - Out of Service' screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

3.10.3.2.2.1 OBFTP Basic System Tests 

The OBFTP performs a basic set of system tests. These tests include: 

1. Basic testing of all OBFTP hardware. This consists of the following tests: 

a. RAM valid signature test 

b. FLASH valid signature and flash command register responses 

c. FRAM control chip signature tests 

d. LCD control chip signature tests 

2. Verification of all external communication links. These include: 


DDU 
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Note: The OBFTP does not communicate directly with the VLU. The OBFTP 
exchanges data with the VLU via the DDU, specifically, using the public 
data area provided by the DDU application. Refer also to section 3.3. 

3. The OBFTP will verify if it is functioning properly. If any tests fail, the OBFTP will enter 
Out of Service/Fault mode. 

4. Any errors detected are logged as UD that will be stored for transfer to the DAC 
during UD transfer. 

3.10.3.2.3 OBFTP Communications Establishment 

This section and its subsections describe the sequence of events that the OBFTP 
undertakes to establish communication with other on-board devices. 


3.10.3.2.3.1 Start-Up Device Communications Operation 


This sequence of steps takes place after power-up and successful completion of OBFTP 


1. The OBFTP will attempt to establish communication with all devices registered as 
installed. The categories of devices for communication purposes are outlined as 
below: 


a. DDU (via Ethernet). 

b. Other OBFTP devices (option). 

Note: The OBFTP does not communicate directly with the VLU. The OBFTP 
exchanges data with the VLU via the DDU, specifically, using the public 
data area provided by the DDU application. Refer also to section 3.3. 

2. If communication is successfully established with all devices registered as installed, 
the OBFTP continues with the power-up sequence. 

3. If communication is not established with one or more devices that have been 
registered as installed: 

a. The OBFTP will record the error as UD for later transfer to the DAC. 

b. In the event that the OBFTP does not detect the DDU, the OBFTP will enter 
Out Of Service mode and display the Out Of Service screen. Refer to the 
‘OBFTP- Out of Service’ screen in the screen-flow presentations in Appendix 
C for the proposed screen. 

4. The OBFTP will continually monitor communications with all installed devices. 


3.10.3.2.3.2 General On-Bus Device Communications Operation 

The following sequence will take place once the OBFTP has completed all power-up 
operations, but communication with a registered device is lost: 

1. If the operator has not logged into the OBFTP: 

a. The OBFTP will record error UD for each installed device for which 
communication could not be established, for later transfer to the DAC. 

SEA-01050-ERG Confidential ©ERG 2010-Page 32 of 2283 

Revision 13.0/Feb 22,2010 To be disclosed only to Agency personnel who 

have a need to know 




Central Puget Sound 

Regional Fare Coordination System 


Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


b. In the event that the OB FTP loses communication with the DDU, the OBFTP 
will enter Out Of Service mode and display the Out Of Service message on the 
OBFTP. Refer to the 'OBFTP - Out of Service' screen in the screen-flow 
presentations in Appendix C for the proposed screen. 

2. If the operator has logged into the OBFTP: 

a. The OBFTP will record error UD for each installed device for which 
communications could not be established, for later transfer to the DAC. 

b. In the event that the OBFTP has not established communication with the DDU, 
the OBFTP will enter Out Of Service mode and display the Out Of Service 
message on the OBFTP. Refer to the ‘OBFTP - Out of Service' screen in the 
screen-flow presentations in Appendix C for the proposed screen. 

c. If the device that lost communications reestablishes communication with the 
OBFTP, the OBFTP will record Communications reestablished UD for that 
device for later transfer to the DAC. 


3.10.3.2.3.3 Ethernet Device Communications Establishment 


This section describes those actions that the OBFTP takes when it powers up and begins 
communication with other OBFTPs (optional) connected via the on-board Ethernet 
network. 

OBFTP slave devices may be connected to the OBFTP via the Ethernet. 

1. The OBFTP signals the nominated device via the Ethernet connection. This causes 
the device to begin initial communications with the OBFTP. This must be done on a 
device-by-device basis so that the OBFTP can associate a physical location with the 
assigned communications parameters for subsequent control purposes. It also allows 
for easier swap-out of faulty devices. 

2. If the nominated device has not replied within a fixed period, the OBFTP will mark this 
device as being out of service and periodically attempt to establish communications 
with it. 

3. If the nominated device replies before the timeout, the OBFTP will mark this device as 
available. 


3.10.3.2.3.4 DAC Communications Establishment 


The following sequence will take place once the OBFTP has become operational (i.e. the 
OBFTP has completed all power-up operations), and a connection is to be established to 
the DAC: 

1. The OBFTP tries to connect to the DAC. 

2. The DAC attached to the WDOLS replies with the communications parameters that 
the OBFTP is to use for this communications session. 

3. The OBFTP then establishes the data connection using the data recovered in step 1. 

4. The OBFTP transfers all unsent UD to the DAC. 

5. The DAC updates any required CD files on the OBFTP. 

6. The OBFTP breaks the connection to the DAC when all data transfer is complete. 
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Note: The DDU will support via the DDU executive application(s) the exchange 
of CD from the DAC directly to the DDU. No CD is required to be 
transferred from the OBFTP to the DDU. 


3.10.3.2.3.5 Alternate CD and UD Transfer 

If connection to the DAC cannot be established via the WDOLS, data can be transferred 
by the alternate communications medium. The connection is a point-to-point connection 
via the OBFTP diagnostics connector. Connection via the alternate data path is 
established by the following procedure: 

• The operator connects a diagnostic PC to the OBFTP diagnostic port and enables the 
alternate data path as described in section 3.10.3.17. 

3.10.3.2.4 Exit Conditions 


1. If the OBFTP fails any self-tests, it will enter Out of Service/Fault mode and the start¬ 
up sequence is terminated. 

2. If the OBFTP has not been previously configured (and is an uninitialized device), the 
OBFTP will progress to Device Configuration mode. 

3. If the OBFTP has been powered off or reset and the operator was logged in and the 
OBFTP can perform initialization of operational routines, it enters the mode of 
operation active before being reset or turned off, thereby terminating the power-up 
sequence. 

4. If the OBFTP has passed self tests and no data transfer is required then the OBFTP 
will progress to Logon Mode. 

Note: Per section 3.10.3.11.12 Locked mode is not used for the RFCS project, 
and therefore will be disabled. 


3.10.3.3 Out of Service/Logon Mode 

This section describes those actions that take place whenever a supervisor, technician, 
or operator wants to log on to the OBFTP. This sequence can only take place when the 
OBFTP is in OOS/Logon mode. 

The OBFTP supports smart card or manual logon. Smart card and manual logon are 
mutually exclusive. CD is used to define the logon type for each Agency. 
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Figure 5: Logon Mode 

3.10.3.3.1 Entry Conditions 

Out of Service/Logon mode will be entered when: 

1. All start-up operations were successful and the CD set is complete and valid. 

2. When the OBFTP is in End Shift mode and there is no input for longer than a CD- 
configurable timeout. 

3.10.3.3.2 Sequence of Events 

1. The OBFTP proceeds to check if there is sufficient space for the storage of additional 
UD. 

a. If there is insufficient space for the storage of additional UD, the OBFTP enters 
Memory Full mode and this sequence ends. 

b. The OBFTP checks if there is any UD (UD storage not full) that needs to be 
transferred to the DAC. 

c. If there is any UD (UD storage not full) that needs to be transferred to the DAC, 
the OBFTP enters Data Transfer mode. 

2. The OBFTP periodically checks that the CD set is complete and valid. 

a. If the CD set is incomplete or invalid, the OBFTP enters Data Transfer mode 
and this sequence ends. 
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3. The OBFTP checks the CD-configured logon mode for the device. Agencies can 
nominate if they require smart card logon or manual logons. Note that in the absence 
of the OBFTP only manual logon is possible. 

a. If the OBFTP is configured for smart card logon, the logon via smart card and 
password sequence of events is followed as outlined in section 3.10.3.3.3. The 
OBFTP sends the Out of Service: Enter Password screen details to the DDU. 
Refer to the ‘DDU - Automatic Logon’ screens in the screen-flow presentations 
in Appendix C for the proposed screens. 

b. If the OBFTP is configured for manual logon, the manual entry of Operator ID 
and Password sequence of events is followed as outlined in section 3.10.3.3.4. 
The OBFTP sends the Out of Service: Enter Operator ID and Password screen 
details to the DDU. Refer to the ‘DDU - Manual Logon' screens in the screen- 
flow presentations in Appendix C for the proposed screens. 

Note: Password properties can include: 

1. The password can be 1 to 8 digits long (length is configurable and dictated 
by what is encoded on the card). 

2. The password is stored on the operator smart card or in CD for manual 
logon validation. 

3. An operator with appropriate privileges can reset the password for an 
operator card. This functionality can be disabled via CD. 

There are passwords on the cards when they are issued to the Agencies. The Agencies 

are advised of the initial passwords at this time, and advised that it should be changed. 

(Changing the operator card password is described in section 3.10.3.18.2.) Refer to the 

Operator Card Management sections in SEA-01355 Card Procurement, Distribution, and 

Management (DR 3 & DR 4) [47], 


3.10.3.3.3 Logon via Smart Card and Password 

1. From the Out of Service mode: Enter Password screen, the operator has the following 

choices: 

a. If the operator enters a valid password and presses the <OK> hotkey, the 
Automatic Role selection is enabled throughout the remainder of this sequence. 
Refer to the ‘DDU - Automatic Logon' screens in the screen-flow presentations in 
Appendix C for the proposed screens. 

b. If the operator enters a valid password and then presses the Manual Role 
Selection key, manual role selection is enabled throughout the remainder of this 
sequence. Refer to the ‘DDU - Role Select' screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

2. The OBFTP checks the role selection method selected in step 1 of this procedure: 

a. If Automatic Role selection was selected, the OBFTP moves to step 4 of this 
procedure. 

b. If Manual Role Selection was selected, this sequence continues. 

3. The OBFTP sends the Out of Service:Select Operational mode screen details to the 

DDU. Refer to the ‘DDU - Mode Select' screens in the screen-flow presentations in 
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Appendix C for the proposed screens. This allows the operator to select a role 
applicable for the OBFTP. The roles applicable to the OBFTP are: 

a. Supervisor Operations. 

The OBFTP Supervisor Operation sequence will be performed if the Supervisor 
Operation> hotkey is pressed. 

b. Maintenance Operations 

The OBFTP General Maintenance sequence will be performed if the 
Maintenance Operation> hotkey is pressed. 

c. Operator Operations . 

The On Shift sequence will be performed if the cOperator Operations> hotkey 
message is received from the DDU. 

4. The OBFTP prompts the operator to present an operator smart card. The OBFTP 
display shows the Present Card for Logon screen. The OBFTP sends the Out of 
Service: Present Operator Card screen details to the DDU. Refer to the 'DDU - 
Automatic Logon’ screens in the screen-flow presentations in Appendix C for the 
proposed screens. 

a. If an operator card is presented to the contactless smart card reader/writer within a 
CD-determined period of time, this sequence continues. 

b. If the operator does not present an operator card to the contactless smart card 
reader/writer within a CD-determined period of time, or if the <Cancel> hotkey 
message is received from the DDU, the OBFTP will timeout on the current screen 
and send the Out of Service: Enter Password screen details to the DDU. Refer to 
the ‘OBFTP & DDU -Logon Cancel' screens in the screen-flow presentations in 
Appendix C for the proposed screens. 

5. The OBFTP checks the entered password against details on the operator card. 

a. If the entered password matches the password on the operator card, this 
sequence continues. 

b. If the entered password does not match the password from the operator card, the 
OBFTP sends the Out of Service: Incorrect Password Entered screen details to 
the DDU. The OBFTP display shows the Invalid Logon screen for a CD-defined 
delay. Refer to the ‘OBFTP & DDU - Invalid Password' screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

The OBFTP increments the password entry retry counter on the operator card and 
performs the next sequence based on the following logic: 

i. If the CD-defined number of password retries has not been exceeded, the 
OBFTP returns to step 1 of this procedure. 

ii. If the CD-defined number of password retries has been exceeded, the operator 
card is blocked from further use. The OBFTP sends the Out of Service: 
Incorrect Password Entered/OpAp Blocked screen details to the DDU. Refer to 
the ‘DDU - OpAp Blocked’ screen in the screen-flow presentations in 
Appendix C for the proposed screen. The OBFTP returns to step 1) of this 
sequence. 

6. The OBFTP checks the role selection method selected in step 1 of this procedure. 
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a. If the operator selected Automatic Role Selection, the OBFTP records UD for later 
transfer to the DAC, uses the first defined operator role read from the operator 
card and enters that mode. 

b. If the operator selected Manual Role Selection, the OBFTP compares the selected 
role to the roles returned from the operator card. 

i. If the selected role corresponds to a role on the operator card, the OBFTP 
enters the appropriate mode and displays the Logon Successful screen for a 
CD-defined period. The OBFTP records UD for later transfer to the DAC and 
proceeds to the selected mode. Refer to the ‘OBFTP - Successful Logon’ 
screen in the screen-flow presentations in Appendix C for the proposed 
screen. 

ii. If the selected role does not correspond to a role on the operator card, the 
OBFTP sends the Out of Service: Invalid Operational Role Chosen screen 
details to the DDU and maintains these details for a CD-defined period. The 
OBFTP display shows the Invalid Logon screen for a CD-defined delay. The 
OBFTP then records UD indicating the logon failure for later transfer to the 
DAC. The OBFTP then returns to step 1 of this procedure. Refer to the 
‘OBFTP & DDU - Invalid Role' screens in the screen-flow presentations in 
Appendix C for the proposed screens. 
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3.10.3.3.4 Manual Entry of Operator ID and Password 

1. From the Out of Service: Enter Operator ID screen, the operator enters the desired 
Operator ID and presses the <OK> hotkey. 

2. The OBFTP sends the Out of Service: Enter Operator Password for Manual Logon 
screen details to the DDU. Refer to the ‘DDU - Enter Password’ screen in the screen- 
flow presentations in Appendix C for the proposed screen. This prompts the operator 
to enter the Operator Password. 

a. If the operator enters a Password followed by the <OK> hotkey within a CD- 
determined period of time, Automatic Role Selection is enabled throughout the 
remainder of this sequence and the sequence continues at step 4. 

b. If the operator enters a Password and presses the <Select Role> hotkey within a 
CD-determined period of time, Manual Role Selection is enabled throughout the 
remainder of this sequence. Refer to the ‘DDU - Role Select’ screens in the 
screen-flow presentations in Appendix C for the proposed screens. 

a. If the operator does not enter an Operator Password followed by the <OK> hotkey 
within a CD-determined period of time or the operator presses the <Cancel> 
hotkey, the OBFTP will time out and return to step 1 of this sequence. 

3. The OBFTP sends the Out of Service:Select Operational mode screen details to the 
DDU. Refer to the ‘DDU - Role Select' screens in the screen-flow presentations in 
Appendix C for the proposed screens. This allows the operator to select a role 
applicable for the OBFTP. The roles applicable to the OBFTP are: 

a. Supervisor Operations 

The OBFTP Supervisor Operation sequence will be performed if the Supervisor 
Operation> hotkey is pressed. 

b. Maintenance Operations 

The OBFTP General Maintenance sequence will be performed if the 
Maintenance Operation> hotkey is pressed. 

c. Operator Operation . 

The On Shift sequence will be performed if the <Driver> hotkey is pressed. 

4. The OBFTP checks the validity of the logon by validating the Operator ID and 
password against details contained in CD. 

a. If the logon is invalid due to the Operator ID, the OBFTP sends the Out of Service: 
Logon Failed screen details to the DDU. The OBFTP display shows the Invalid 
Logon screen for a CD-defined delay. Refer to the ‘OBFTP & DDU - Logon Failed’ 
screens in the screen-flow presentations in Appendix C for the proposed screens. 
A UD record is created indicating the logon failure. The OBFTP returns to step 1 of 
this sequence. 

b. If the logon is invalid due to an incorrect password, the OBFTP sends the Out of 
Service: Logon Failed screen details to the DDU. The OBFTP display shows the 
Invalid Logon screen for a CD-defined period. Refer to the ‘OBFTP & DDU - 
Logon Failed’ screens in the screen-flow presentations in Appendix C for the 
proposed screens. A UD record is created indicating the logon failure. The OBFTP 
returns to step 1 of this sequence. 
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Note: Unlike the feature for automatic smart card logons where the operator card 
is blocked if a password retry count is exceed, no such blocking applies 
for manual logons as it cannot be system-wide (i.e. carry over from bus to 
bus) and could disadvantage a driver if the operator ID has been used by 
others. 

c. If the logon is valid, this sequence continues. 

5. The OBFTP checks the role selection method selected in step 2 of this sequence: 

a. If Automatic Role Selection was selected, the OBFTP records UD for later transfer 
to the DAC and determines the operator role based on CD and enters that mode. 
Multiple roles may be defined for an operator in CD. In this case, the role with the 
highest precedence is chosen. The order of precedence is Driver followed by 
Supervisor, followed by Maintainer. Hence, if an operator has both Supervisor and 
Maintainer roles defined, Supervisor will be chosen. If an operator has no valid 
roles defined in CD, then the OBFTP proceeds to step 7 of this sequence. 

b. If Manual Role Selection was selected, the OBFTP compares the selected role to 
the roles returned from the CD. 

6. If the selected role corresponds to a role in CD, the OBFTP sends the appropriate 
screen details of the entered mode to the DDU. The OBFTP display shows the Logon 
Successful screen for a CD-defined delay. The OBFTP records UD for later transfer to 
the DAC and proceeds to the selected mode. Refer to the 'OBFTP & DDU - 
Successful Logon’ screens in the screen-flow presentations in Appendix C for the 
proposed screens. 


7. If the selected role does not correspond to a role in CD, the OBFTP sends the Out of 
Service: Invalid Role screen details to the DDU. The OBFTP display shows the Invalid 
Logon screen for a CD-defined delay. The OBFTP records UD indicating the logon 
failure for later transfer. The OBFTP then returns to step 1 of this sequence. Refer to 
the ‘OBFTP & DDU - Invalid Role' screens in the screen-flow presentations in 
Appendix C for the proposed screens. 
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Figure 7: Manual Logon Mode Sequence of Events 


?.1Q.3.3.5 Operator Logon Triggered by DDU FIM Application 

In FIM, a mechanism exists for a manual login to be triggered by the 3 rd party provided 
FIM application residing on the DDU This mechanism involves the DDU’s FIM 
application communicating login information to the OBFTP application via the Public 
Shared Data. Refer to section [ 191 for more details of this process. 
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1. FIM is enabled. 


2. The operator role bpecified Iby the FIM application is valid. A value of 0 is considered . commented [d2]: com-v 12 .o-ooi 
to be the same as the default Driver role and, hence, is valid. 


3. The DDU/OBFTP are in Logon mode. 

4. The driver has NOT progressed the I 
case of a Manual Login) or the Enter 
based Login) as this means he/she ii 
be interrupted. 


3.10.3.3.5 3.10.3.3.6 Exit Conditions Commented [d3]: change order #32 


Out of Service/Logon mode will be exited if: 

1. A valid logon is completed; this will result in a change to the configured/selected 
mode. 

2. A CD/UD transfer is required and a transition to Data Transfer mode is automatically 
or manually initiated. 

3. The vehicle ignition switch is off and the OBFTP has been idle for greater than the 
CD-defined timeout. 
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3.10.3.4 Data Transfer Mode 



Device installation 



3.10.3.4.1 Entry Conditions 

Data Transfer mode is entered under the following conditions: 

1. From Start-up mode, if CD is missing or incomplete. 

2. From End Shift mode, if UD transfer is required. 

3. From OOS/Logon mode, if a CD/UD transfer has not occurred for a configurable 
period. 

4. From OOS/Logon mode, if a CD/UD transfer is required. 

5. From OOS/Logon mode, if the device has determined that there is UD accumulated 
that has not yet been transferred. 


ERG Confidential © ERG 2010 
To be disclosed only to Agency personnel who 
have a need to know 


SEA-01050 

Revision 13.0/Feb 22, 2010 


Page 44 of 2283 






Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


Central Puget Sound 

Regional Fare Coordination System 

3.10.3.4.2 Sequence of Events 



Figure 9: Out of Service CD/UD Transfer Sequence of Events 
The following automatic sequence will take place once a connection is to be established 
with the DAC: 

1. The OBFTP displays the Out of Service screen. The OB FTP sends the Out of 
Sen/ice: CD/UD Transfer Required screen details to the DDU. Refer to the 'DDU - 
CD/UD Transfer' screens in the screen-flow presentations in Appendix C for the 
proposed screens. The following sequence is then initiated: 

a. The OBFTP establishes data connection with the DAC. 

b. Once the connection has been established, the OBFTP transfers all UD not yet 
sent to the DAC. 

c. The OBFTP sends the Out of Service: CD/UD Transfer screen to the DDU. This 
screen contains the CD filename that is being downloaded to the device and the 
number of files to be downloaded (progress bar indicates status of each CD file 
download). Refer to the ‘DDU - CD/UD Transfer' screens in the screen-flow 
presentations in Appendix C for the proposed screens. The DAC updates any 
required CD files on the OBFTP including: 

■ Latest application and OS (if required) 

■ Fare tables and business rules 

■ Actionlists 

■ Date and time 

[Note: if Data Transfer mode is entered from Start-Up mode immediately after the 

vh-F'iT i i I n; ■ ii . ill 1 .i I ■ I' - ■ I l■, ■ I hi ■ i 1 . i ■ ■ i M . in." I ■ ■: 

CD payloads, i.e.. actionlist payloads, from the DAC. This is done to reduce 

CD download times prior to initially going on-shift after power-uo. Any 

: i n I C !■ i :i '' n. I '.i ill .. 1 ,, .!■■.-■ i -I .'.ill !■■■ I ■ i ■!■. I 

at this time. Subsequently, when Data Transfer mode is entered from 

'>!'.■ L' .. ill- i lli- lr I Oi ■■ i. i'. -i !■ ■■ Ml . i ‘ I ■ ..'I ii|- III- ■ I- i' ■ ..II 

be configured to download all CD payloads that contain changes 

Note: The DDU will support via the DDU executive application(s) the exchange 
of CD from the DAC directly to the DDU. No CD is required to be 
transferred from the OBFTP to the DDU. 

d. The OBFTP breaks the connection to the DAC when all data transfer is complete. 

2. For alternate data path connections (see section 3.10.3.17 for information on how to 
enable the alternate data path): 

a. The OBFTP attempts to establish a serial PPP connection on the serial 
diagnostics connector of the OBFTP. 

SEA-01050-ERG Confidential © ER#!#-Paga 45 of 2283- 

Revision 13.0/Feb 22, 2010 To be disclosed only to Agency personnel who 


id [d4]: RFI #236, SERM #1-001128, EQP- 















Central Puget Sound Fare Transaction Processor (DR 

Regional Fare Coordination System Security Level 3 102B) - Functional Specification 

b. The OBFTP broadcasts its identity over the PPP serial link. 


c. The portable computer attached to the PPP serial link replies with the 
communications parameters that the OBFTP is to use for this communications 
session. 

d. The OBFTP then establishes the data connections using the data recovered in 
step c). 

e. The OBFTP transfers all UD not yet sent to the portable computer. 

f. The portable computer updates any required CD files on the OBFTP. 

g. The OBFTP breaks the connection to the portable computer when all data transfer 
is complete. 


3.10.3.4.3 Exit Conditions 


The Data Transfer mode will be exited if the CD/UD transfer is completed successfully or 
if the OBFTP cannot establish communications with the DAC/portable computer. 


3.10.3.5 


Out of Service/Fault Mode 

Out of Service/Fault mode is entered when, on start-up, the OBFTP has an internal fault 
that prevents it from performing correctly. 



Figure 10: Out of Service/Fault Mode 


Entry Conditions 

If an error is encountered during Start-up mode, Out of Service/Fault mode will be 
entered. 


Sequence of Events 

On entering Out of Service/Fault mode, the following sequence of events takes place: 

1. The OBFTP sends the Out of Service: Fault screen details to the DDU, while the 
OBFTP display shows the Fault screen. Refer to the 'OBFTP & DDU - OOS Fault' 
screens in the screen-flow presentations in Appendix C for the proposed screens. 
Both screens will provide the operator with the following fault information: 

a. Device address 

b. Device ESN 

c. Fault reason 
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d. Fault code 

2. The Fault mode UD will be logged in the OBFTP, along with the reason for putting the 
OBFTP into Fault mode. 

Note: The fault may prevent some or all operations from occurring and the device 
behavior cannot be guaranteed. 

3.10.3.5.3 Exit Conditions 

The Out of Service/Fault mode will be exited when: 

1. The OBFTP is reset or switched off. 

2. When a maintenance card is presented to the CSC reader/writer. 

OBFTP resets are software controlled. The device is switched off under software control 
or by removing it from its cradle. 

Note: If the fault is associated with the CSC reader/writer, the OBFTP will not be able 
to enter Maintenance mode. 

3.10.3.6 Out of Service/Memory Full Mode 

Out of Service/Memory Full mode prevents on-trip operation if there is inadequate space 
for the storage of additional UD. 
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J.10.3.6.1 Entry Conditions 

Out of Service/Memory Full mode will be entered when an asynchronous UD full event is 
triggered. Out of Service/Memory Full mode can be entered any time while in the 
following modes: 

1. Out Of Service/Logon mode 

2. On Shift mode 

3. Select Route/Run mode 

4. Select Trip mode 

5. Any On Trip mode 

6. Select Route/Run mode 

7. Select Trip mode 

3.10.3.6.2 Sequence of Events 




Figure 12: Out of Service/Memory Full Mode Sequence of Events 
1. If on trip: 
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a. The Memory Full screen details are sent to the DDU. Refer to the ‘DDU - Memory 
Full' screen in the screen-flow presentations in Appendix C for the proposed 

b. The trip end and shift end will be forced. 

2. If on shift: 

a. The shift end will be forced. The OBFTP will attempt to upload its UD to the DAC. 


3.10.3.6.3 Exit Conditions 


The OBFTP will exit Out of Service/Memory Full mode and enter Data Transfer mode if a 
connection has been established to the DAC. 


On Shift Mode 

The OBFTP will enter On Shift mode when the operator is logged on. The OBFTP is now 
in operation. 



Figure 13: On Shift Mode 


3.10.3.7.1 Entry Conditions 

The OBFTP will enter On Shift mode after a successful logon operation. 
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3.10.3.7.2 Sequence of Events 

When the OBFTP is in On Shift mode, the OBFTP will proceed directly to Select 
Route/Run mode. 


3.10.3.7.3 Exit Conditions 

The OBFTP will enter Select Route/Run mode after shift processing has completed. 


Select Route/Run Mode 

This section describes those actions that take place after an operator logs on. The option 
to select the route/run is available from On Shift or On Trip modes. 

Note: Selection of route/run represents the association of trips to be performed 
by an operator. While individual agencies use slightly different terms, 
mode transitions represented here still apply. The specific screens, and 
associated terms used by each Agency are shown in the screen-flow 
presentations in Appendix C. 



[Note: In FIM, the display of the Select Route/Run and Select Trip screens on the 
DDU is the responsibility of the FIM application residing on the DDU. In 
this case, the OBFTP still enters the Select Route/Run mode if coming 

from Out Of Service/Logon mode. However, the screens provided by the 

DDU FIM application will override those rendered by the OBFTP. For more 

details refer to SEA-01048 Driver Display Unit (DR 103B) - Functional 

_[19]_ 
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Entry Conditions 

Select Route/Run mode is entered after a successful logon, or when the Select 

Route/Run hotkey message is received from the IDDU and LIM is enabledl. 

Note: In actual fact, the transitions from Select Trip or On Trip modes are via 
End Trip mode. However, End Trip mode is a necessary mode transition in 
order to perform end of trip processing, not apparent to the operator, and 
so not shown in Figure 14 for clarity. Refer to section 3.10.3.11 for details 
of End Trip mode. 


Commented [d6]: Change Order #32 


Sequence of Events 

1. The OBFTP sends the Select Route/Run screen details to the DDU. Refer to the 
‘DDU - Select Route/Run' screen in the screen-flow presentations in Appendix C for 
the proposed screen. 

a. This screen prompts the operator to enter a route/run number. 

b. If the <Cancel> hotkey message is received from the DDU or the OBFTP does not 
receive any operator input within the CD-defined inactivity time, the OBFTP 
returns to the OOS/Logon mode. 

c. If a route/run is entered and the <OK> hotkey message is received from the DDU, 
the OBFTP validates the route/run number against values stored in configuration 

i. If the route/run number is valid, the OBFTP saves the route/run information. 

ii. If the route/run number is invalid, i.e. not contained in CD, the OBFTP sends 
the Invalid Route/Run screen details to the DDU and prompts the operator to 
enter a new value. Refer to the ‘DDU - Invalid Route/Run' screen in the 
screen-flow presentations in Appendix C for the proposed screen. 


3.10.3.8.3 Exit Conditions 


1. If the <Cancel> hotkey message is received from the DDU, the OBFTP will return to 
Out of Service/Logon mode. 

if the route/run selection was completed successfully, the OBFTP enters 
Select Trip mode. 

2. 3. In FIM, if the OBFTP receives a request to enter On Trip mode with a specified 

route/run and trip from the DDU FIM application and the provided route/run/trip 

information can be used to identify a valid run and trio in the device’s CD. then the 

OBFTP accepts this request and enters On Trip n i. Commented [d7]: changeorder#32 


3.10.3.9 Select Trip Mode 

This section describes those actions that take place after an operator has completed 
selection of a route/run. The option to select a trip is available from Select Route/Run or 
On Trip modes. 
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Figure 15: Select Trip Mode 

[Note: In FIM, this mode will not be entered after the OBFTP exits from Select 

Route/Run mode as the ' 

On Trip mode. Addition! 
mode when the Select Ti 
the display of the Select ’ 

FIM application residing ____ _ __ 

Driver Display Unit (DR 103B) - Functional Specification [19L |__ { Commented [d8]: change Order 


FTP is directed to bypass this mode and enter 
this mode will not be entered from On Trip 
hotkey message is received from the DDU, as 
) screen on the DDU is the responsibility of the 
the DDU. For more details refer to SEA-01048 


3.10.3.9.1 Entry Conditions 

Select Trip mode is entered after the operator has successfully selected a route/run, or 
when the Select Trip hotkey message is received from the DDU. 

Note: In actual fact, the transition from On Trip mode is via End Trip mode. 
Flowever, End Trip mode is a necessary mode transition in order to 
perform end of trip processing, not apparent to the operator, and so not 
shown in Figure 15 for clarity. Refer to section 3.10.3.11 for details of End 
Trip mode. 


Sequence of Events 

The OBFTP sends the Select Trip screen details to the DDU. Refer to the ‘DDU - Select 
Trip' screen in the screen-flow presentations in Appendix C for the proposed screen. 
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1. This screen contains a list of trips sorted in time order, with the first trip starting after 
the current time as the default selection. The operator can enter a trip number and/or 
use the menu handling functionality to select a different trip from the list. 

2. If the <Cancel> hotkey message is received from the DDU or the OBFTP does not 
receive any operator input within the CD-defined inactivity time, the OBFTP returns to 
the Select Route/Run mode. 

3. If a trip is selected and the <OK> hotkey message is received from the DDU, the 
OBFTP saves the trip information selected. 


3.10.3.9.3 Exit Conditions 


1. If the <Cancel> hotkey message is received from the DDU, the OBFTP will return to 
Select Route/Run mode. 

2. If the trip selection was successfully completed, the OBFTP enters On Trip mode. 


3.10.3.10 On Trip Mode 

On Trip mode is reached after an operator has logged on and successfully completed the 
selection of a route/run and a trip. On Trip is the main mode from which the operator and 
OBFTP perform fare collection functions. 

Note: The functionality for the On Trip mode has been flattened to allow on trip 
functions to be spread across more than one DDU decal. Refer to SEA- 
01048 Driver Display Unit (DR 103B) - Functional Specification [19] for 
details on DDU template management, and the AFC application running on 
the DDU. 
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Figure 16: On Trip Mode 


3.10.3.10.1 Entry Conditions 

1. If the select route/run and trip operations are successfully completed, the OBFTP 
enters On Trip mode. 

2. After changing to a different trip, the OBFTP will return to On Trip mode. 

3. After reversing a transaction, the OBFTP will return to On Trip mode. 

4. After setting up a group transaction, the OBFTP will return to On Trip mode. 

5. After a fareset has been selected for a single transaction fare override, the OBFTP will 
return to On Trip mode. 

6. After a fareset has been selected for the default fare, the OBFTP will return to On Trip 

7. If the Cancel hotkey on the DDU is pressed for the Device Control mode screen, the 
OBFTP will return to On Trip mode. 
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Note: A number of transitions in Figure 16 also include a transition if the cancel 
hotkey is pressed or a configurable timeout occurs. 

3.10.3.10.2 Sequence of Events 

1. When the OBFTP is in On Trip mode, the OBFTP displays the Auto Entry/Exit screen 
and is ready to accept cardholder fare cards for processing. The OBFTP sends the 
On Trip screen details to the DDU. Refer to the ‘OBFTP & DDU - On Trip' screens in 
the screen-flow presentations in Appendix C for the proposed screens. 

2. The On Trip screen details sent to the DDU include the following information: 

a. Current route/run 

b. Current trip 

c. Current route 

d. Current fareset 

e. Configured adult fare 

f. Trip origin 

g. Trip destination . 

3. The On Trip screen on the OBFTP displays the following information: 

a. Current time 

b. Current fareset. 

4. From On Trip mode, the operator can perform the following functions: 

a. Select the next trip 

b. Change the route/run 

c. Change the trip 

d. Change the fareset 

e. Perform a fare (zone) override 

f. Reverse the last transaction 

g. Perform a group fare transaction 

h. Increment ridership counters 

i. Record passenger headcount 

j. Logoff (end shift) 

k. OBFTP device control 

l. Lock the OBFTP (this feature is disabled, refer to sections 3.10.3.11.12 and 
3.10.3.13) 
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Note: Fareset names for the different distance codes (including free ride) are 
included in CD for each participant. Where the CD contains routes for 
multiple participants, as is the case for agencies operating ST services in 
addition to their own, the correct fareset names corresponding to the 
participant owning the route will be displayed on the OBFTP and DDU. 
Details of the submodes and functions of On Trip mode are included in section 3.10.3.11 
and subsections. 


3.10.3.10.3 Exit Conditions 


1. If the Next Trip hotkey message is received from the DDU, the OBFTP transitions to 
End Trip mode and then on to On Trip mode. 

2. If the Select Trip hotkey message is received from the DDU, the OBFTP transitions to 
End Trip mode and then on to On Trip mode. 

3. If the Logoff hotkey message is received from the DDU, the OBFTP transitions to End 
Trip mode and then on to End Shift mode. 

Note: From the operator’s perspective, End Trip mode occurs in the background 
and is a necessary transition between trips or between a trip and the end 
of a shift in order to produce end of trip usage data required for reporting 
purposes. Refer to section 3.10.3.11 for details of End Trip mode. 


3.10.3.11 On Trip Submodes and Functions 


3.10.3.11.1 Select Next Trip 

This function provides the operator the ability to advance to the next trip without having to 
go through the trip selection process as described for Select Trip mode in section 
3.10.3.9. If the operator needs to select a trip out of sequence the Select Trip function 
described in section 3.10.3.11.3. 

i LIM, .hen the Select Next Trip hotkey message is received from the DDU. the commented [d9]: change order #32 

OBFTP sends the Next Trip Confirmation screen details to the DDU. Refer to the ‘OBFTP 
& DDU - Next Trip' screens in the screen-flow presentations in Appendix C for the 
proposed screens. 

From the DDU, the operator will be able to confirm or deny the change to the next trip. 

The <No> hotkey reverts back to the On Trip screen without any changes recorded. The 
<Yes> hotkey records the new trip and returns to the On Trip screen to display the new 
trip details. Refer to the ‘OBFTP & DDU - Next Trip' screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

Iln FIM, the Select Next Trip button is not generally displayed on the DDU until a point in 

time just prior to reaching the end-of-trip location. At that time the DDU FIM application 

directs the DDU to display a message asking the driver to confirm the change to the next 

trip. At the same time it displays the “Select Next Trip” hotkey for the driver to press to 

trigger this confirmation. After the driver presses the “Select Next Trip” hotkey, the DDU 

FIM application communicates the next trip's information to the OBFTP through the 

Shared Public Data on the DDU. 

The OBFTP will then validate the trip information. The result of this validation is then 

communicated back to the DDU FIM application via Shared Public Data variables on the 

DDU. If this step is successful, the trip change is completed, the trip information is fed 
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back to the other DDU applications including the DDU FIM application via Shared Public 

Commented [dlO]: Change Order #32 

As part of ending the current trip (prior to commencing the next trip, the OBFTP will 
record the entire current trip UD. After the UD is saved, the OBFTP starts the next trip. 

Once the last trip has been selected, the OBFTP changes the Next Trip icon on the DDU 
to indicate to the operator that there are no more trips for this route/run. When the last trip 
has been selected, the Select Next Trip hotkey message from the DDU will not cause any 
action. Refer to the ‘DDU - Last Trip' screen in the screen-flow presentations in Appendix 
C for the proposed screen. 


3.10.3.11.2 Select Route/Run 


This function provides the operator the ability to change the route/run. This can be 
applied at any time while in On Trip mode. 

Iln LIM, Wwhen ^he Select route/run hotkey message is received from the DDU, the commented [dll]: changeorder#32 

OBFTP goes to the Select Route/Run mode. Changing to the Select Route/Run mode 

sends the Select Route/Run screen details to the DDU, while the OBFTP displays the 

Out of Service screen. Refer to section 3.10.3.8 for a description of the Select Route/Run 

mode. Refer to the ‘OBFTP & DDU - Select Route/Run' screens in the screen-flow 

presentations in Appendix C for the proposed screens. 

Note: Following the change of route/run the OBFTP will transition to the Select 
Trip mode as illustrated in Figure 14. 

Iln FIM, the display of the Select Route/Run and Select Trip screens on the DDU is the 

responsibility of the FIM application residing on the DDU. In this case, the OBFTP does 

not enter Select Route/Run mode. For more details refer to SEA-01048 Driver Display 

Unit (DR 103B1 - Functional Specification [191 . Rather, the OBFTP transitions to End Trip 
mode. 

When the OBFTP receives a request to re-enter On Trip mode with a specified route/run 

and trip from the DDU FIM application and the provided route/run/trip information can be 

used to identify a valid run and trip in the device's CD, then the OBFTP accepts this 

request and enters On Trip mode again. |_ { Commented [d!2]: Change Order #32 


3.10.3.11.3 Select Trip 

This function provides the operator the ability to change the trip. This can be applied at 
any time while in On Trip mode. This function is used when the operator wishes to 
change to a trip out of the normal time advance sequence. Refer also to section 
3.10.3.11.1 on changing to the next trip. 

Iln LIM. Wwhen ^he Select Trip hotkey message is received from the DDU, the OBFTP Commented [dl3]: changeorder#32 

goes to the Select Trip mode. Changing to the Select Trip mode sends the Select Trip 

screen details to the DDU, while the OBFTP displays the Out of Service screen. Refer to 

section 3.10.3.8 for a description of the Select Trip mode. Refer to the 'OBFTP & DDU - 

Select Trip’ screens in the screen-flow presentations in Appendix C for the proposed 

screens. 

Iln FIM, the display of the Select Trip screen on the DDU is the responsibility of the FIM 

application residing on the DDU. In this case, the OBFTP does not enter Select Trip 

mode. For more details refer to SEA-01048 Driver Display Unit (DR 103B1 - Functional 

Specification f 191 . Rather, the OBFTP transitions to End Trip mode. 
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Select Fareset Mode 


At the start of a trip the OBFTP will assign the default fareset as defined in configuration 
data to be the current fareset. Iln FIM only, the OBFTP indicates, through the DDU 
Shared Public Data variables, that the default fareset (distance code) has not been 

T.a ■~ n.ia.ly chan g ed by i l o drive:. T he operator can change the fareset at other times 
during the trip, at which point the new fareset will apply until the end of the trip or until 
changed again. To change the fareset for only one transaction, the Fare Override mode 
is used. 


3.10.3.11.4.1 Entry Conditions 

The Select Fareset mode entry conditions are: 

1. The OBFTP is in On Trip mode. 

2. If the Select Fareset hotkey message is received from the DDU, the OBFTP enters 
Select Fareset mode_or>. 

3. In FIM only, the OBFTP receives a request from the DDU FIM application, through the 

DDU Shared Public Data variables, to change the current fareset and the driver has 

not manually changed the current fareset since the start of the current trip, the OBFTP 

enters Select Fareset mode. 

3t£L _When the OBFTP is in the Select Fareset mode, the operator cannot perform 

other AFC functions.. Commented [dl6]: Change Order #32 ~) 

3.10.3.11.4.2 Sequence of Events 

1. When the Select Fareset hotkey message is received from the DDU, the OBFTP 
sends the Select Fareset screen details to the DDU, while the OBFTP displays the 
Out of Service screen. Refer to the ‘OBFTP & DDU - Select Fareset’ screens in the 
screen-flow presentations in Appendix C for the proposed screens. 

2. If the <Cancel> hotkey message is received from the DDU the OBFTP returns to the 
On Trip mode. 

3. The OBFTP Select Fareset screen sent to the DDU has menu entries for each fareset 
defined in configuration data for the current trip. Only the faresets defined in 
configuration data for the current trip will be selectable. Note that it is the operator’s 
responsibility to select the appropriate fareset for the service in progress. 

4. The operator selects the new fareset by scrolling to the desired fare set (using up and 
down hotkeys). When the OK hotkey is pressed th e s ele ct e d far e s e t , the OBFTP 
returns to the On Trip mode and updates the On Trip screen details on the DDU with 
the new fareset. Iln FIM only, the OBFTP indicates, through the DDU Shared Public 
Data variables, that the default fareset (distance code) has been manually changed bv 

When the new fareset has been selected, the OBFTP displays the On Trip commented [di7]: change order #32 

mode Idle screen. Refer to the ‘DDU - Select Fareset' screen in the screen-flow 
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presentations in Appendix C for the proposed screen. Refer to section 3.10.3.11.14 
for details of fare processing. 

4 45. Alternatively, in FIM only, if the OBFTP receives a request from the DDU FIM 

application, through the DDU Shared Public Data variables, to change the current 

fareset the OBFTP validates that the specified fareset is valid for the current trip. The 

OBFTP then provides feedback of the result of this request to the DDU FIM 

application through the DDU Shared Public Data variables. The OBFTP returns to the 

On Trip mode and updates the On Trip screen details on the DDU with the new 

[ Commented [dl8]: Change Order 


3.10.3.11.4.3 Exit Conditions 

After selection of a fareset or a configurable timeout occurring, the OBFTP returns to On 
Trip mode. 

3.10.3.11.5 Fare (Zone) Override Mode 

At any time during a trip there is a current fareset in use. The fareset may be the default 
fareset for the trip (as defined in configuration data), or may have been changed with the 
Select Fareset mode as described in section 0. To change the fareset applicable to a 
single (next) transaction and return to the current fareset automatically, the operator can 
use the Fare Override mode. 


3.10.3.11.5.1 Entry Conditions 

The Fare Override mode entry conditions are: 

1. The OBFTP is in On Trip mode. 

2. If the Fare Override hotkey message is received from the DDU the OBFTP enters 
Fare Override mode. 


3.10.3.11.5.2 Sequence of Events 

1. When the Fare Override hotkey message is received from the DDU, the OBFTP 
sends revised On Trip screen details to the DDU. 

a. The OBFTP will change the fareset to the next fareset in the list of available 
faresets configured in CD for the current trip. 

2. Note that unless the current fareset is for zone distance zero (0), i.e. ride free, the 
OBFTP will not override to this fareset. This fareset will be skipped and the OBFTP 
will override to the next available fareset. 

3. The On Trip screen detail on the DDU includes a description of the fareset that 
applies at any time. When a fare override applies, the revised On Trip screen details 
indicates if an override condition applies. Refer to the ‘DDU - Fare Override’ screen in 
the screen-flow presentations in Appendix C for the proposed screen. 

a. The OBFTP cycles through available faresets with each Fare Override hotkey 
message received from the DDU, returning to the first fareset when the last 
available fareset is reached. 
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b. When the fareset cycles and returns to the current (no override) fareset, the 
override will no longer apply and the revised On Trip screen details sent to the 
DDU will not indicate a fare override condition. Refer to the ‘DDU - Fare Override’ 
screen in the screen-flow presentations in Appendix C for the proposed screen. 

4. Whenever an override condition applies, the OB FTP screen displays the Fare 
Override prompt screen. Refer to the ‘OBFTP - Fare Override' screen in the screen- 
flow presentations in Appendix C for the proposed screen. 

5. If the cardholder fare card is presented to the contactless smart card reader/writer 
within the CD-defined inactivity time, the OBFTP performs the fare transaction on the 
fare card. Refer to section 3.10.3.11.15 for details of the OBFTP and DDU screens 
applicable to processing transactions. 

6. After the transaction has completed or a configurable timeout has occurred, the 
OBFTP sends the On Trip screen to the DDU and the OBFTP displays the On Trip 
Idle screen. Refer to the ‘OBFTP & DDU - Fare Override' screens in the screen-flow 
presentations in Appendix C for the proposed screens. 


3.10.3.11.5.3 Exit Conditions 


After the fare card transaction has completed or a configurable timeout has occurred, the 
OBFTP returns to On Trip mode. 


J.10.3.11.6 Reverse Transaction Mode 

If the operator or cardholder makes an error, the operator will be able to reverse the fare 
payment paid by the cardholder dependent on Agency business rules (refer to SEA- 
00090 Business Architecture [3]). 


3.10.3.11.6.1 Entry Conditions 

The Reverse Transaction mode entry conditions are: 

1. The OBFTP is in On Trip mode. 

2. If the Reverse Transaction hotkey message is received from the DDU the OBFTP 
enters Reverse Transaction mode. 

3. When the OBFTP is in the Reverse Transaction mode, the operator cannot perform 
other AFC functions. 

4. The following criteria must be met before a reversal will be allowed: 

a. Reversals can only occur on the same OBFTP that generated the transaction 
being reversed. 

b. The operator can only reverse a certain number of transactions during the reversal 
period. This is defined by two CD parameters, the number of reversals, and the 
reversal period. 

c. The reversal can only occur if it is attempted within the CD-defined time, the 
reversal time limit. 


ERG Confidential © ERG 2010 
To be disclosed only to Agency personnel who 
have a need to know 


SEA-01050 

Revision 13.0/Feb 22, 2010 




Central Puget Sound 

Regional Fare Coordination System 


Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


3.10.3.11.6.2 Sequence of Events 

1. When the Reverse Transaction hotkey message is received from the DDU, the 
OBFTP sends the Reverse Transaction screen details to the DDU and the OBFTP. 
Refer to the ‘OBFTP & DDU - Reverse Transaction' screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

2. If the <Cancel> hotkey message is received from the DDU or the cardholder smart 
card is not presented to the contactless smart card reader/writer within a CD-defined 
inactivity time, the OBFTP returns to the On Trip mode. 

3. If the cardholder fare card is presented to the contactless smart card reader/writer 
within the CD-defined inactivity time, the OBFTP attempts to reverse the last 
transaction on the smart card: 

a. If the reversal is successful, the OBFTP sends the Reverse Transaction 
Confirmation screen (popup) details to the DDU for a CD-defined time period. The 
OBFTP displays the Reverse Transaction Successful screen for a CD-defined 
time period. Refer to the ‘OBFTP & DDU - Reverse Transaction’ screens in the 
screen-flow presentations in Appendix C for the proposed screens. 

b. If the reversal is unsuccessful, the OBFTP sends the Reverse Failure screen 
(popup) to the DDU for a CD-defined delay. The OBFTP displays the Reverse 
Transaction Failure screen for a CD-defined time period. 


3.10.3.11.6.3 Exit Conditions 


1. After presentation of the fare card or after a configurable timeout, the OBFTP returns 
to On Trip mode. 

2. If there is no operator input for a CD-defined timeout, the OBFTP returns to On Trip 
mode. 


3.10.3.11.7 Group Transaction Mode 

The operator can configure the OBFTP to perform a group transaction, i.e. to pay for a 
number of patrons with a single fare card transaction. 


3.10.3.11.7.1 Entry Conditions 

The Group Transaction mode entry conditions are: 

1. The OBFTP is in On Trip mode. 

2. If the Group Transaction hotkey message is received from the DDU the OBFTP enters 
Group Transaction mode. 

3. When the OBFTP is in the Group Transaction mode, the operator cannot perform 
other AFC functions. 

Note: Group transactions apply to the current fareset, or to a different fareset if 
a fare override condition applies. In the case of a fare override condition 
applying, the fare override will be removed after the transaction 
completes, at which point the current fareset will apply once again. Refer 
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to sections 3.10.3.11.4, and 3.10.3.11.5 for details on Select Fareset and 
Fare Override modes. 


3.10.3.11.7.2 Sequence of Events 

1. When the Group Transaction hotkey message is received from the DDU, the OBFTP 
sends the Group Transaction screen details to the DDU, and the OBFTP displays the 
Out of Sen/ice screen. Refer to the ‘OBFTP & DDU - Group Transaction' screens in 
the screen-flow presentations in Appendix C for the proposed screens. 

2. If the <Cancel> hotkey message is received from the DDU the OBFTP returns to the 
On Trip mode. 

3. The operator increments the number of each patron type in the group by selecting the 
appropriate DDU hotkey. When one of the patron type increment hotkeys is received 
from the DDU, the OBFTP updates the Group Transaction screen details on the DDU 
with the group makeup and fare total for the group. Refer to the ‘DDU - Group 
Transaction' screen in the screen-flow presentations in Appendix C for the proposed 
screen. Refer to section 3.10.3.11.14 for details of fare processing. 

4. After the group makeup has been entered, the operator presses the <OK> hotkey. 
When the <OK> hotkey message is received from the DDU, the OBFTP sends the 
Group Transaction screen details to the DDU and the OBFTP. Refer to the ‘OBFTP & 
DDU - Group Transaction' screens in the screen-flow presentations in Appendix C for 
the proposed screens. 

5. If the cardholder fare card is presented to the contactless smart card reader/writer 
within the CD-defined inactivity time, the OBFTP attempts to perform the group 
transaction on the smart card. 

a. If the group transaction is successful, the OBFTP sends the Group Transaction 
Confirmation screen (popup) details to the DDU for a CD-defined time period. The 
OBFTP displays the Group Transaction Successful screen for a CD-defined time 
period. Refer to the ‘OBFTP & DDU - Group Transaction’ screens in the screen- 
flow presentations in Appendix C for the proposed screens. 

b. If the group transaction is unsuccessful, the OBFTP sends the Group Transaction 
Failure screen (popup) to the DDU for a CD-defined delay. The OBFTP displays 
the Group Transaction Failure screen for a CD-defined time period. 


3.10.3.11.7.3 Exit Conditions 


1. After presentation of the fare card or after a configurable timeout, the OBFTP returns 
to On Trip mode. 

2. If there is no operator input for a CD-defined timeout, the OBFTP returns to On Trip 


3.10.3.11.8 Ridership Counters 

This function provides the operator the ability to increment any of the Agency ridership 
counters. The counters can be incremented at any time while in On Trip mode. 

Each Agency can define the counters that it wishes to make available by defining them in 
configuration data. The configuration data definition for counters includes an index to a 
list of counters defined for the RFCS project (systemwide). 
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Note: The decals on the DDU need to include hotkey definitions and icons to 
cover all the counters defined in the OBFTP configuration data. Note also 
that the counters may be spread across one or more decals depending on 
the available space on each decal and the total number of counters a 
particular Agency requires. 

When any of the Ridership Counter hotkey messages are received from the DDU, the 
OBFTP generates event UD to increment the counter associated with the hotkey 
message. Incrementing ridership counters does not result in any changes to the On Trip 
screens for either the DDU or OBFTP. 


3.10.3.11.9 Passenger Headcount 

This function provides the operator the ability to record the passenger headcount. Use of 
this function is entirely up to the operator, as is the actual counting of the passengers. 
This function is only available during On Trip mode. 

When the Passenger Headcount hotkey message is received from the DDU, the OBFTP 
sends the Passenger Headcount screen details to the DDU. The OBFTP screen is not 
affected. Refer to the ‘DDU - Passenger Headcount’ screen in the screen-flow 
presentations in Appendix C for the proposed screen. 

The Passenger Headcount screen allows the operator to enter a value for the passenger 
headcount. From the Passenger Headcount screen: 

1. If the <Cancel> hotkey message is received from the DDU, the OBFTP returns to the 
On Trip mode screen. 

2. If the <OK> hotkey message is received from the DDU, the OBFTP records the 
passenger headcount entered in UD, and returns to the On Trip mode screen. If no 
headcount value is entered, a count of zero is recorded in UD. 


5.10.3.11.10 Logoff 

This function allows operators to log off and end their shifts. This can be applied at any 
time while in On Trip mode, with the result that the current trip and shift are ended. 

From the DDU, the operator will be able to confirm or deny the logoff request. The <No> 
hotkey reverts back to the On Trip screen without ending the current shift. The <Yes> 
hotkey ends the current shift and sends the OOS/Logon screen details to the DDU, while 
the OBFTP displays the Out of Service screen. Refer to section 3.10.3.3 for a description 
of the OOS/Logon mode and to section 3.10.3.15 for a description of the End Shift mode. 

Refer to the ‘OBFTP & DDU - Logoff screens in the screen-flow presentations in 
Appendix C for the proposed screens. 

Iln FIM, operator logoff can also be triggered bv the DDU FIM application bv request 

through the DDU Shared Public Data variables. The result of this request is returned by 

the OBFTP to the DDU FIM application through the DDU Shared Public Data variables. If 

not successful, the OBFTP reverts to the On Trip screen without ending the current shift. 

If successful, the OBFTP ends the current shift and sends the OOS/Logon screen details 

Commented [d!9]: Change 0,* 


OBFTP Device Control 

This function allows the operator to adjust OBFTP device settings like display contrast 
and brightness. 
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When the Device Control hotkey message is received from the DDU, the OBFTP goes to 
OBFTP Device Control mode (refer to section 3.10.3.14). The DDU and OBFTP screens 
for OBFTP Device Control mode are also described in section 3.10.3.14. 


3.10.3.11.12 OBFTP Lock 

This function allows the operator to lock the OBFTP so that it is unavailable for fare 
collection. 

When the Lock hotkey message is received from the DDU, the OBFTP goes to Locked 
mode (refer to section 3.10.3.11). Locking the OBFTP sends the Locked screen details to 
the DDU, while the OBFTP displays the Out of Sen/ice screen. 

Note: Following a regional decision in the DDU/OBFTP design finalization 
workshops [42][43], ERG understands that Locked mode is not required 
for the OBFTP. Locked mode will consequently be disabled in the OBFTP. 
Note that a sleep function is to be implemented in the DDU (refer to SEA- 
01048 Driver Display Unit (DR 103B) - Functional Specification [19]), 
however this does not impact the OBFTP software. 

3.10.3.11.13 Business Rules Calculations 

The first step in any fare card business rules calculation will be the validation of the 
cardholder fare card. This will involve a series of checks such as (but not limited to) 
hotlist, expiration date and participant ID. Operator cards are also validated as part of the 
operator logon. 

Business rules are contained in SEA-00090 Business Architecture [3]. Table 9 provides 
an example of business rules checks that may be performed when a cardholder or 
operator card is presented to the card reader/writer. 


Table 9: Card Validation Checks (Example) 






Description 


Product Expiration 

If a validity period for the product type (i.e. 
period pass) exists and the period is going to 
expire in less than a CD-defined period, the 
OBFTP displays the Imminent Period Pass 
Entry Expiration screen. Refer to the 'OBFTP 
- Product Expiry Warning’ screens in the 
screen-flow presentations in Appendix C for 
the proposed screens. 

Note that product expiration warnings are 
inhibited if the product is configured on the 
fare card for an automatic revalue. 


If the detected card is located in the device 
hotlist/actionlist, the card may be blocked in 
accordance with a CD-defined parameter. 

The OBFTP will display the Blocked Card 
screen, and the OBFTP will also send the 
card detail to the DDU. Refer to the 'OBFTP & 
DDU - Card Blocked’ screens in the screen- 
flow presentations in Appendix C for the 
proposed screens. 

If the detected card has an electronic value 
that is greater than a CD-defined limit, the 
card is blocked in accordance with a CD- 
defined parameter. 

The OBFTP will display the Excessive 
Electronic Value screen, and the OBFTP will 
also send the card detail to the DDU. Refer to 
the 'OBFTP & DDU - Invalid Card’ screens in 
the screen-flow presentations in Appendix C 
for the proposed screens. 






Description 


Auto Revalue Disabled 

If Auto Revalue is not enabled and the 
remaining value on the card is less than the 
threshold value as specified in CD, the Low 
Value screen is displayed. 

If the card value is insufficient for the cost of 
the trip, a partial payment transaction is 
generated. The OBFTP will display the 
Insufficient Value screen with the amount 
owing, and the OBFTP will send the Amount 
Owing details to the DDU. Refer to the 
'OBFTP & DDU - Underpayment’ screens in 
the screen-flow presentations in Appendix C 
for the proposed screens. 

Auto Revalue Enabled 
If Auto Revalue is enabled and the remaining 
value on the card is less than the threshold 
value as specified in CD, the Low Value 
screen will not be displayed. 

The card is credited with a pre-defined 
amount. The OBFTP will display the Auto 
Revalue Complete screen and the 
corresponding usage data will be generated. 
Refer to the ‘OBFTP - Card Revalue’ screens 
in the screen-flow presentations in Appendix 
C for the proposed screens. 


If the card is not issued for use in the program 
(for example in the RFCS project), the card 
may be blocked in accordance with a CD- 
defined parameter. 

If an undefined card type is used, the OBFTP 
will display the Invalid Card screen, and the 
OBFTP will send the card detail to the DDU. 
Refer to the 'OBFTP & DDU - Invalid Card’ 
screens in the screen-flow presentations in 
Appendix C for the proposed screens. 

If a card is presented more than once within 
the CD-defined time limit, the transaction is 
aborted. 

The OBFTP will display the Card Reuse 
screen, and the OBFTP will send the card 
detail to the DDU. Refer to the 'OBFTP & 

DDU - Passback’ screens in the screen-flow 
presentations in Appendix C for the proposec 
screens. 
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3.10.3.11.14 Fare Processing 

The cardholder can pay for the fare using the fare card only via the following payment 
methods: 

1. Electronic purse 

2. Period product 

3. Stored rides 

Note: Actionlist processing may also be occurring that revalues or adds products 
to the fare card that may be used for fare payment. In addition, 
institutional program fare cards may also have electronic voucher 
processing occurring that may revalue or add products to the fare card 
that may be used for fare payment. 

Note: Normal fares can be reduced by transfer discounts as allowed for in 
business rules (refer to SEA-00090 Business Architecture [3]). 

Fares in general can be derived from the CD based on the passenger type, product type, 
time of day, type of day, zones/stops/distance traveled, and other service characteristics. 
Configuration data for each trip includes pointers to all the faresets applicable to that trip, 
including which fareset is the default fareset to be applied at the start of the trip. Fareset 
information includes the base fares to be charged for each passenger type, as well as the 
fareset description to be written to the OBFTP screen and sent to the DDU. 

In On Trip mode the operator can select an alternate fareset (from the faresets defined in 
CD for each trip) to be applied from that point forward (until changed again) or for only 
the next transaction in the case of a fare override. Refer to sections 0 and 3.10.3.11.5. 
The operator can configure the product parameters (Passenger Type = Adult, Child; 
Product Type = Single, Return, etc.) along with the origin or destination zone to 
determine the fare to be charged. After the operator has configured the fare parameters, 
the amount of fare to be paid will be displayed. The cardholder will be prompted to 
present the smart card to the contactless smart card reader/writer. 

See SEA-00430 ERGRFI 00086 Origin & Destination in UD [16] for more information. 
Refer to section 3.10.3.11.15 for details of the screens applicable to the OBFTP and DDU 
for fare processing. 


Transaction Processing 

As per sections 3.10.3.11.13 and 3.10.3.11.14, the OBFTP processes fare card 
transactions based on business rules and various fare calculation parameters either 
defined in configuration data, specified on the fare card, or selected by the operator. 

Fare transaction processing results in the following outputs: 

• OBFTP screen - Results of the transaction are displayed to the patron and include, if 
applicable, the fare paid and the remaining value/period of the fare card purse/product 
as illustrated in Figure 17 (and as shown in the Transaction Layout screens of the 
screen flows in Appendix C). 
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Transaction field 


□ c 


Payment field 
Alert field 
Balance field 


Figure 17: OBFTP Transaction Display Format 

Only a single OBFTP transaction screen is displayed, for a configurable time or until the 
next fare card is processed. Other actions can occur during a fare transaction, e.g., an 
autoload or actionlist process, as well as warnings following a transaction, e.g., a low 
purse warning. For these reasons the fields in Figure 17 represent a hierarchy of display 
messages. 

The Transaction field indicates the type of transaction with the following order of 
precedence (highest to lowest): 

• OWE - If an underpayment condition exists, in which case the Payment field indicates 
the amount owing. 

• XFER - If a transfer condition exists, in which case the Payment field indicates any 
additional amount paid from the purse. 

• PASS - If a pass product was used, in which case the Payment field indicates any 
additional amount paid from the purse. The same applies for other product types that 
are valid methods of payment, e.g., rides. 

• PAID - If only the purse was used to pay for the fare, in which case the Payment field 
indicates the fare paid. 

The Alert field indicates a warning message as a result of the transaction with the 
following order of precedence (highest to lowest): 

• Autoload advice - If a revalue action was processed before the fare processing. 

• Low value warning - If the purse balance is below a configurable threshold value 
after the fare processing completes. 

• Pass expiration warning - If the time to expiration of the pass product used is within 
a configurable time. 

Note: Purse low value and pass product expiration warnings are inhibited if the 
purse or pass product as applicable is configured for automatic revalue on 
the fare card. 

The Balance field indicates the remaining value of the fare card purse, and it includes the 
result of the fare calculation and any autoload or actionlist processing. 

Examples of the OBFTP screens illustrating all the combinations of the fields described 
above are included in the ‘OBFTP - Transaction Display' screens in the screen-flow 
presentations in Appendix C. 

• OBFTP status LEDs - Results of the transactions, including warnings, are indicated 
by various combinations of status LEDs. 

Refer to section 3.9.1.1 for details of the LED status indications. The LED status 
indications are also included in the ‘OBFTP - Transaction Display’ screens in the 
screen-flow presentations in Appendix C. 

• OBFTP audio - Results of the transactions, including warnings, are indicated by 
various combinations of tones. 
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Refer to section 3.9.1.2 and Appendix B for details of the audio indications. The audio 
indications are also included in the ‘OBFTP - Transaction Display' screens in the 
screen-flow presentations in Appendix C. 

• DDU screen - The OBFTP sends a popup to the AFC screen on the DDU to mirror 
the indication on the OBFTP. 

Note: The popup sent from the OBFTP to the DDU is written to a configurable 
position on the AFC window on the DDU. Note that the popup will only be 
visible if the AFC window on the DDU is visible, i.e. it will not overwrite the 
windows of other applications. 

The DDU popups will be displayed for a configurable period and then clear automatically. 

Alternatively they are cleared by a new popup message from the OBFTP. Refer to the 

‘DDU - Transaction Display’ screens in the screen-flow presentations in Appendix C for 

the proposed screens. 

• The OBFTP does not send a popup to the DDU for cardholder warnings, e.g., low 
value, or autoload processing. 

• The OBFTP does not send a popup to the DDU for fare transactions that involve a 
valid transfer. 

• The OBFTP sends a popup to the DDU for all discount (not full fare) transactions. 
Note that the DDU popup indicates only the passenger type and the fare; it does not 
show the balance of the fare card purse. 

• For an underpayment situation, the OBFTP displays the Underpayment screen and 
sends the Underpayment screen (popup) details to the DDU. Refer to the ‘OBFTP & 
DDU - Underpayment' screens in the screen-flow presentations in Appendix C for the 
proposed screens. 

o In an underpayment situation, the popup sent to the DDU will prompt the 
operator to address the underpayment situation and will persist until the operator 
presses the <OK> hotkey to acknowledge the underpayment or until a 
configurable timeout occurs. 

o While the underpayment popup is still active on the DDU screen, the OBFTP will 
display the Underpayment screen and will not process any other transactions, 
o If the <OK> hotkey message is received from the DDU, the OBFTP will remove 
the popup from the display. The operator can then choose to reverse the 
transaction or accept a cash payment for the amount owing. 


Invalid and Incomplete Transactions 

For transactions or attempted transactions that do not result in a fare transaction as 
described in section 3.10.3.11.15, error or warning screens are displayed on the OBFTP 
and screen details sent to the DDU. Refer to the 'OBFTP & DDU - Invalid Transaction' 
and ‘OBFTP & DDU - Incomplete Transaction’ screens in the screen-flow presentations 
in Appendix C for the proposed screens. 
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3.10.3.12 End Trip Mode 




Figure 18: End Trip Mode 


3.10.3.12.1 Entry Conditions 

End Trip mode occurs in the background, and it is a necessary transition between trips or 
between a trip and the end of a shift in order to produce end of trip usage data required 
for reporting purposes. End Trip Mode will be entered when the Select Trip, Next Trip, 
Select Route/Run, or Logoff hotkey messages are received from the DDU while the 
OBFTP is in On Trip mode. 

Additionally, in FIM only. End Trip Mode will be entered upon successful request by the 

DDU FIM application to change route/run/trip information or perform an operator logoff.l 


3.10.3.12.2 Sequence of Events 

1. The OBFTP records the entire trip UD. 

2. After the UD is saved, the OBFTP enters one of the following modes: 

a. If the Logoff hotkey message was received from the DDU, the OBFTP goes to End 
Shift mode. Refer to sections 3.10.3.11.10, and 3.10.3.15. 
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b. In LIM, (if |either the Next Trip or Select Trip hotkey messages were received from commented [d2i]: change order #32 

the DDU, the OBFTP goes to Select Trip mode. Refer to sections 3.10.3.9, 

3.10.3.11.1, and 3.10.3.11.3. 

c. Iln LIM. i ff ^he Select Route/Run hotkey message was received from the DDU, the commented [d22]: change order #32 

OBFTP goes to Select Route/Run mode. Refer to sections 3.10.3.8 and 

3.10.3.11.2. 

d. Iln FIM, if the OBFTP receives a successful request from the DDU FIM application. 

through the DDU Shared Public Data variables, to change route/run/trip 

information, the OBFTP returns to On Trip mode and displays the new 

route/run/trip information. Refer to sections 3.10.3.9. 3.10.3.11.1 _ 3.10.3.11.3. 

3.10.3.8 and 3.10.3.11.2. 

fe e. In FIM, if the OBFTP receives a successful reguest from the DDU FIM 

application, through the DDU Shared Public Data variables, to logoff, the OBFTP 

goes to End Shift mode. Refer to sections 3.10.3.11.10 3.10.3.15, [_ [commented [d23]: change order #32 ~) 


3.10.3.12.3 Exit Conditions 

End Trip mode will be exited when the OBFTP either progresses to End Shift mode, 

Select Route/Run jnode, 01 Select Trip mode , or On Trip mode after |he End Trip Commented [d24]: changeorder#32 

Sequence has been completed. 


3.10.3.13 Locked Mode 

Locked mode prevents unauthorized operation of the OBFTP from the DDU while the 
operator is absent. Locking the device allows the operator to leave the DDU unattended 
without terminating the Trip or Shift. 

Note: Refer to section 3.10.3.11.12, which indicates that the Locked mode for 
the OBFTP is inhibited for the RFCS project. However, details of Locked 
mode are included in this document for completeness. 
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Figure 19: Locked Mode 


Entry Conditions 

Locked mode may be manually entered at any time after a successful logon and before 
logoff. 

Locked mode is entered: 

1. When the OBFTP is in On Trip mode and the OBFTP does not receive operator input 
for longer than a CD-configurable timeout. 

2. If the OBFTP is powered off while in On Trip mode for longer than the CD- 
configurable time and then powered back on. 


Sequence of Events 

1. The OBFTP records an event UD when Locked mode is entered. 

2. The OBFTP sends the Locked screen details to the DDU. 

3. If the OBFTP was in On Trip mode before the OBFTP entered Locked mode, the 
OBFTP remains in service and the OBFTP displays the Auto Entry/Exit screen to 
process cardholder fare cards. 

4. The OBFTP retains the operator's details. These details are used to determine if the 
same or a different operator subsequently unlocks the OBFTP. 

5. The steps to unlock the device depend on the initial logon method, as described in the 
following subsections. 
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1. The OBFTP sends the OBFTP Locked screen details to the DDU. 

a. If the CD-defined Logoff time expires, the OBFTP progresses to End Shift mode. 

b. If the <Enter> hotkey message is received from the DDU, this sequence 
continues. 

2. The OBFTP sends the Out of Service: Enter Password screen details to the DDU. The 
operator has the following choices: 

a. If the Password Entered hotkey message is received from the DDU, and then the 
<Enter> hotkey message is received from the DDU, the Automatic Role Selection 
is enabled throughout the remainder of this sequence. 

b. If the Password Entered hotkey message is received from the DDU, and then the 
Manual Role Selection hotkey message is received from the DDU, Manual Role 
Selection is enabled throughout the remainder of this sequence. 

3. The OBFTP display shows the Present Card for Logon screen and prompts the 
operator to present the operator card to the contactless smart card reader/writer. The 
OBFPT sends the Present Operator Card screen details to the DDU. 

a. If the operator presented an operator smart card to the contactless smart card 
reader/writer within the CD-determined period of time, this sequence continues. 

b. If the operator does not present an operator smart card to the contactless smart 
card reader/writer within a CD-determined period of time or the <Cancel> hotkey 
message is received from the DDU, the OBFTP returns to OOS/Logon mode and 
this sequence terminates. 

4. If the same operator presents the operator card, the OBFTP enters the mode active 
before it was locked. 

5. If a different operator smart card is presented, the OBFTP takes one of the following 
actions: 

a. If the OBFTP was in On Trip mode, the new operator is forced to end the existing 
Trip and Shift or cancel the unlock operation. 

6. The OBFTP records the Unlock action to UD. 


3.10.3.13.2.2 Manual Entry of Operator ID and Password 


1. The OBFTP sends the OBFTP Locked screen details to the DDU. 

a. If the CD-defined logoff time expires, the OBFTP progresses to End Shift mode. 

b. If the <Enter> hotkey message is received from the DDU, this sequence 
continues. 

2. The OBFPT sends the Out of Service: Enter Password screen details to the DDU. The 
operator has the following choices: 

a. If the Password Entered hotkey message is received from the DDU, and then the 
<Enter> hotkey message is received from the DDU, Automatic Role Selection is 
enabled throughout the remainder of this sequence. 
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b. If the Password Entered hotkey message is received from the DDU, and then the 
Manual Role Selection hotkey message is received from the DDU, Manual Role 
Selection is enabled throughout the remainder of this sequence. 

3. The OBFTP sends the Out of Service: Enter Operator ID screen details to the DDU. 

The operator has the following choices: 

a. If the Operator ID Entered hotkey message is received from the DDU and then the 
<Enter> hotkey message is received from the DDU within a CD-determined period 
of time, this sequence continues. 

b. If the OBFTP does not receive the inputs specified in step 3 a) within the CD- 
determined period of time or the <Cancel> hotkey message is received from the 
DDU, the OBFTP will time out and this sequence terminates. 

4. The OBFTP validates the Operator ID and password. 

a. If the Operator ID and password are the same as used at logon, the OBFTP 
returns to the mode active before it was locked. 

b. If a different Operator ID is entered with a correct password, the OBFTP takes one 
of the following actions: 

i. If the OBFTP was in On Trip mode, the new operator is forced to end the 
existing Trip and Shift or cancel the unlock operation 

5. The OBFTP records the unlock action as UD. 


3.10.3.14 OBFTP Device Control 

This function allows the operator to adjust OBFTP device settings like display contrast 
and brightness. 

OBFTP device control functions are available when the OBFTP is in the following modes: 

1. On Trip mode 

2. Maintenance mode 

When the OBFTP Device Control hotkey message is received from the DDU, the OBFTP 
sends the OBFTP device control screen details to the DDU. Refer to the ‘OBFTP & DDU 
- OBFTP Device Control’ screens in the screen-flow presentations in Appendix C for the 
proposed screens. 

The following subsection describes the sequence of events associated with all the 
OBFTP device control functions. 


3.10.3.14.1 Sequence of Events 

From the OBFTP device control screen the operator has the option to configure the 
OBFTP display and speaker volume as illustrated in Figure 20 and described below. 
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Figure 20: OBFTP Device Control Sequence of Events 


3.10.3.14.2 OBFTP Device Configuration 

If the OBFTP Device Control hotkey message is received from the DDU, the OBFTP 
sends the OBFTP Device Control screen details to the DDU. Refer to the 'OBFTP & DDU 
- OBFTP Device Control' screens in the screen-flow presentations in Appendix C for the 
proposed screens. The screen allows the display contrast, brightness, and speaker 
volume to be adjusted to suit the operator. The level of each setting can only be adjusted 
between CD-defined upper and lower limits. From this screen, the operator can perform 
the following options: 

1. Adjust Brightness (Backlight) 

a. If the Adjust Brightness hotkey message is received from the DDU, the OBFTP 
sends the OBFTP Adjust Brightness screen details to the DDU. From this screen, 
the operator has the option of increasing (up arrow) or decreasing (down arrow) 
the brightness of the OBFTP LCD. Changes to the screen brightness are reflected 
on the OBFTP display as changes are made. 

b. If the OBFTP detects a timeout, the OBFTP sends the OBFTP Device Control 
screen details to the DDU and the brightness will not be changed. 

c. If the <OK> hotkey message is received from the DDU, the OBFTP will save the 
changes in the OBFTP. The OBFTP sends the OBFTP Device Control screen 
details to the DDU. 










Central Puget Sound 

Regional Fare Coordination System 


Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


2. Adjust Contrast. 

a. If the Adjust Contrast hotkey message is received from the DDU, the OBFTP 
sends the OBFTP Adjust Contrast screen details to the DDU. From this screen, 
the operator has the option of increasing (up arrow) or decreasing (down arrow) 
the contrast of the OBFTP display. Changes to the screen contrast are reflected 
on the OBFTP display as changes are made. 

b. If the OBFTP detects a timeout, the OBFTP sends the OBFTP Device Control 
screen details to the DDU and the contrast will not be changed. 

c. If the <OK> hotkey message is received from the DDU, the OBFTP will save the 
changes in the OBFTP. The OBFTP sends the OBFTP Device Control screen 
details to the DDU. 

3. Adjust Volume 

a. If the Adjust Volume hotkey message is received from the DDU, the OBFTP sends 
the OBFTP Adjust Volume screen details to the DDU. From this screen, the 
operator has the option of increasing (Up Arrow) or decreasing (Down Arrow) the 
volume of the OBFTP audio. The OBFTP emits a tone at the current volume 
setting as changes are made. 

b. If the OBFTP detects a timeout, the OBFTP sends the OBFTP Device Control 
screen details to the DDU and the volume will not be changed. 

c. If the <OK> hotkey message is received from the DDU, the OBFTP will save the 
changes in the OBFTP. The OBFTP sends the OBFTP Device Control screen 
details to the DDU. 

4. If the <Cancel> hotkey message is received from the DDU, the OBFTP sends the On 

Trip mode or Maintenance mode (as applicable) screen details to the DDU. 


3.10.3.14.3 Exit Conditions 


When the <Cancel> hotkey message is received from the DDU, the OBFTP enters its 
previous mode (either On Trip mode or Maintenance mode). 


3.10.3.15 


End Shift Mode 

This section describes those actions that take place whenever an operator who has 
logged in as an operator wants to end the current shift. 
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Entry Conditions 

End Shift mode may be entered when: 

1. The Logoff hotkey message is received from the DDU while the OBFTP is in On Trip 

2. A CD-defined timeout is reached in Locked mode. 

2^ 3. Iln FIM only, if the OBFTP receives a successful request from the DDU FIM 

application, through the DDU Shared Public Data variables, to perform an operator 

Commented [d25]: Change Order 

Note: Refer to section 3.10.3.11.12, which indicates that the Locked mode for 
the OBFTP is inhibited for the RFCS project. 
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Figure 22: End Shift mode Sequence of Events 


Sequence of Events 

1. When the Logoff hotkey message is received from the DDU, the OBFTP sends the 
Logoff Confirmation screen details to the DDU. There is no change to the OBFTP 
display. Refer to the ‘DDU - Logoff Confirmation’ screen in the screen-flow 
presentations in Appendix C for the proposed screen. 

a. |lf the <No> hotkey message is received from the DDU, the OBFTP returns to the 
On Trip mode screen and the sequence completes . 
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b. If the <Yes> hotkey message is received from the DDU, the OBFTP generates UD 
to record the end of the current trip and the end of the current shift. The sequence 
then continues at step 3 below. 

2. Alternatively, in FIM only, if the OBFTP receives a request from the DDU FIM 


aDDlication throuah the DDU Shared Public Data var 



ioaoff and either 



a. the reauest is not successful, the OBFTP stavs in 

the On TriD mode screen and 

the seauence comoletes. 



b. the reauest is successful, the OBFTP aenerates 

UD to 

record the end of the 

current trio and the end of the current shift. The seauence i 

then continues at steo 3 


below. 

2.3._The OBFTP transitions to OOS/Logon mode. Refer to section 3.10.3.3 for details 

Of OOS/Logon mode. I Commented [d26]: Change Order 

Note: The OBFTP will stay in OOS/Logon mode for a configurable period before 
entering Data Transfer mode. This is to allow for quick driver relief to 
occur without having to wait for data transfer to be attempted/completed. 

3t 4. The OBFTP resets all user interface characteristics (such as screen contrast) to 
their default values. 

If the configurable Data Transfer delay period elapses, the OBFTP enters the 
Data Transfer mode. 


3.10.3.15.3 Exit Conditions 

End Shift mode will be exited when the OBFTP progresses to either Logon mode or Data 
Transfer mode after the End Shift sequence has been completed. 

3.10.3.16 Training Functions Mode 

Training operation provides full functionality with modified transaction logging. 


3.10.3.16.1 Entry Conditions 

Training Operation is set when a Training Card with the Training bit set is used for logon 
from either Logon mode or Locked mode. The OBFTP switches to Training Operation 
upon completion of the logon. 


3.10.3.16.2 Sequence of Events 

When in Training Operation, the OBFTP will: 

1. Ensure that all UD generated will have the Training bit set in the UD Header. 

2. Ensure that the OBFTP will not increment any audit registers. 

3. Ensure that only cardholder fare cards that have the Training bit set will be accepted 
and processed. 

4. Ensure that all other functionality of the device will be identical to normal operation 
with the exception of the following additional capabilities. 

SEA-01050 ERG Confidential © ERGL2&10 PagsTBof 2283 

Revision 13.0/Feb 22, 2010 To be disclosed only to Agency personnel who 

have a need to know 















Central Puget Sound 

Regional Fare Coordination System 


Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


a. Upon entry to Training Operation, the operator will be presented with screens that 
allow he/she to modify the date/time of the DDU and OBFTP, if and only if the 
OBFTPs rotary switch has been placed in positions 4, 5, 6 or 7. These screens will 
also allow the operator to revert the DDU and OBFTP device time to the correct 


Note: Modification of the date/time on the DDU/OBFTP will persist until the 
operator has logged off and logged on again with training mode disabled 
or logged on again with training mode enabled and manually reverted the 
date/time. 

Note: Any attempt by a DAC to synchronize with a DDU/OBFTP that currently 
have their date/time manually modified in this way will be ignored by the 
DDU/OBFTP. 

b. After a trip has been selected, a hotkey on the Fares 2 screen for ET and the 
Options screen for all other agencies will be provided that triggers the current set 
of service data to be exported to the diagnostic ports of both the DDU and the 
OBFTP in a readable form. Examples of the exported service data format are 
provided below in Table 10. 

Note: The service data exported by the DDU and OBFTP includes the current 
date/time as configured on the device, the Configuration Data version 
number as indicated by the MASSSETA version, the current day types 
associated with the current date, and the valid route/runs and valid trips 
per route/run for the current date/time. 


Table 10: Example files containing exported Service Data 


File 

Description 

3 

kcm_obftp.txt 

Unformatted text file that has been logged by the terminal program - 
TeraTerm. The example file contains KCM service data. 

JB t 

Annotated Microsoft Excel spreadsheet containing the same 
information as the above text file. Excel has been used to open the 
above text file using TAB delimiting. The columns have been 
expanded to fit the information, but no other formatting has been 
applied. Some explanatory notes relating to the format and content 
of the output files have been inserted into certain cells of the Excel 
spreadsheet. 


3.10.3.16.3 Exit Conditions 

The OBFTP will remain in Training Operation until any of the following exit conditions 


1. The shift is ended. 

2. The OBFTP enters Locked mode. 
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3.10.3.17 Maintenance Mode 



Figure 23: Maintenance Mode 


3.10.3.17.1 Entry Conditions 

Maintenance mode will be entered: 

• From Out of Service/Logon mode when an operator card is presented with a valid 
maintenance role privilege and a valid password entry. 
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Figure 24: Maintenance Mode Sequence of Events 

The OBFTP sends the Maintenance mode screen details to the DDU. Refer to the ‘DDU 
- Maintenance Mode’ screen in the screen-flow presentations in Appendix C for the 
proposed screen. From this screen, the maintenance personnel can perform the following 
functionality on the OBFTP: 

• Perform device configuration 

• Use alternate data path 

• Force CD/UD transfer 

• View configuration data (CD) details 

• View audit register (AR) details 
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• Perform device control 

• Perform device self tests 

3. Perform Device Configuration 

If the Device Configuration message hotkey is received from the DDU, the OBFTP 
enters Device Configuration mode. Refer to the ‘OBFTP & DDU - Device 
Configuration’ screens in the screen-flow presentations in Appendix C for the 
proposed screens. Refer also to section 3.10.3.19 that describes Device Configuration 
mode. 

4. Alternate Data Path 

If the Alternate Data Path message hotkey is received from the DDU, the OBFTP 
sends the Alternate Data Path screen details to the DDU. The OBFTP latches the 
request and will attempt a physical connection to a DAC (diagnostic PC) via the 
alternate data path (i.e. not via the vehicle WLAN) when the operator ends the 
(maintenance) shift. Refer to the ‘DDU - Alternate Data Path' screens in the screen- 
flow presentations in Appendix C for the proposed screens. 

Note: The actual DDU data transfer screens for the alternate data path are the 
same as that for the primary data path (i.e. via the WDOLS). 

5. CD/UD Transfer 

When the CD/UD Transfer Options hotkey message is received from the DDU, the 
OBFTP sends the CD/UD Transfer Options screen details to the DDU. The OBFTP 
latches the request and will attempt a CD/UD exchange with the DAC via the primary 
data path (WLAN) when the operator ends the (maintenance) shift. Refer to the 
‘OBFTP & DDU - CD/UD Transfer' screens in the screen-flow presentations in 
Appendix C for the proposed screens. 

6. View CD Details 

When the View CD Details hotkey message is received from the DDU, the OBFTP 
sends the View CD Details screen details to the DDU. This screen displays a list of all 
CD payloads currently retained by the OBFTP, along with the payload size and 
version information. Refer to the ‘DDU - Maintenance View CD’ screen in the screen- 
flow presentations in Appendix C for the proposed screen. 

7. View Audit Registers 

When the View Audit Registers hotkey message is received from the DDU, the 
OBFTP sends the View Audit Registers screen details to the DDU. Refer to the ‘DDU 
- Maintenance View AR’ screen in the screen-flow presentations in Appendix C for 
the proposed screen. This screen contains a list of any defined audit registers and 
their current values. 

8. Device Control 

When the Device Control hotkey message is received from the DDU the OBFTP 
enters Device Control mode and execute the standard device control menu. Refer to 
section 3.10.3.14fordetails of Device Control mode. 

9. Device Self Tests 

When the Device Self Tests hotkey message is received from the DDU, the 
OBFTP sends the Device Self Test screen details to the DDU. Refer to the 'DDU - 
Device Self Tests' screen in the screen-flow presentations in Appendix C for the 
proposed screen. 
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3.10.3.17.3 Exit Conditions 

Maintenance mode will be exited when: 

1. The Logoff hotkey message is received from the DDU, causing the OBFTP to return 
to Out of Service/Logon mode. 

2. The Device Control hotkey message is received from the DDU, causing the OBFTP to 
enter Device Control mode. 

3. The Device Configuration hotkey message is received from the DDU, causing the 
device to enter Device Configuration mode. 

3.10.3.18 Supervisor Mode 



3.10.3.18.1 Entry Conditions 

Supervisor mode is entered from Out Of Service/Logon mode when an operator card is 
presented with a valid supervisor role privilege and a valid password entry. 
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3.10.3.18.2 Sequence of Events 



Figure 26: Supervisor Mode Sequence of Events 

The OB FTP sends the Supervisor mode screen details to the DDU. Refer to the ‘DDU - 
Supervisor Mode’ screen in the screen-flow presentations in Appendix C for the proposed 
screen. From this screen, the supervisor can perform the following functions: 

1. View CD Details 

When the View CD Details hotkey message is received from the DDU, the OBFTP 
sends the View CD Details screen details to the DDU. This screen contains a list of all 
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CD payloads currently retained by the OBFTP, along with the payload size and status. 
Refer to the ‘DDU - Supervisor View CD' screen in the screen-flow presentations in 
Appendix C for the proposed screen. 

2. Display Audit Register Totals 

When the Display Audit Register Totals hotkey message is received from the DDU, 
the OBFTP sends the Display Audit Register Totals screen details to the DDU. This 
screen displays a list of any defined audit registers and their current values. Refer to 
the ‘DDU - Supervisor View AR' screen in the screen-flow presentations in Appendix 
C for the proposed screen. 

3. Display Trip Details 

When the Display Trip Details hotkey message is received from the DDU, the OBFTP 
sends the Display Trip Details screen details to the DDU. This screen contains a list of 
the last five trips start times and dates. Refer to the ‘DDU - Supervisor View Trip 
Details’ screen in the screen-flow presentations in Appendix C for the proposed 
screen. 

4. Device Control 

When the Device Control hotkey message is received from the DDU, the OBFTP 
enters Device Control mode. (See section 3.10.3.14) 

5. Change Operator Card Password 

i. When the Change Operator Card Password hotkey message is received from 
the DDU, the OBFTP sends the Enter New Password screen details to the 
DDU. The operator is allowed to enter the new password (up to 8 digits 
allowed) using the hotkeys on the DDU. Refer to the 'DDU - Change Operator 
Password' screens in the screen-flow presentations in Appendix C for the 
proposed screens. 

ii. When the operator has entered the new password and the <OK> hotkey 
message is received from the DDU, the OBFTP sends the Present Card for 
New Password screen details to the DDU. The OBFTP displays the Present 
Operator Card screen and prompt the operator to present the operator card to 
the contactless smart card reader/writer. Refer to the ‘DDU - Change Operator 
Password' screens in the screen-flow presentations in Appendix C for the 
proposed screens. 

iii. If an operator card is not presented to the contactless smart card reader/writer 
within a CD-determined period of time or the OBFTP does not receive operator 
input from the DDU, the OBFTP will time out. The OBFTP sends the password 
Change Unsuccessful screen details to the DDU. The OBFTP displays the 
Change Password Failure screen. Refer to the ‘OBFTP & DDU - Change 
Operator Password Failed’ screens in the screen-flow presentations in 
Appendix C for the proposed screens. The OBFTP then returns to the 
beginning of step 5) in this sequence. 

iv. If an operator card is presented to the contactless smart card reader/writer 
within a CD-determined period of time, the new password will be stored on the 
operator card. The OBFTP sends the password Change Successful screen 
details to the DDU. The OBFTP display will show the Change Password 
Success screen. Refer to the ‘OBFTP & DDU - Change Operator Password 
Successful' screens in the screen-flow presentations in Appendix C for the 
proposed screens. The OBFTP then returns to the beginning of step 5) in this 
sequence. 
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i. When the Unblock Operator Card hotkey message is received from the DDU, 
the OBFTP sends the Present Operator Card screen details to the DDU. The 
OBFTP also displays the Present Operator Card screen and prompts the 
operator to present a blocked operator card to the contactless smart card 
reader/writer. Refer to the 'Unblock Operator Card' section in the screen-flow 
presentations in Appendix C for the proposed screens. 

ii. If an operator card is not presented to the contactless smart card reader/writer 
within a CD-determined period of time and the OBFTP does not receive 
operator input from the DDU, the OBFTP will time out. The OBFTP then 
returns to the beginning of step 6) in this sequence. 

iii. If an unblocked operator card or an operator card that is blocked for some 
reason other than too many PIN retry failures, is presented to the contactless 
smart card reader/writer within a CD-determined period of time, the OBFTP 
sends the 'Unblock Card Failure' screen details to the DDU. The OBFTP 
displays the 'Unblock Card Failure' screen. Refer to the 'Unblock Operator 
Card’ section in the screen-flow presentations in Appendix C for the proposed 
screens. The OBFTP then returns to the beginning of step 6) in this sequence. 

iv. If an operator card that is blocked due to too many PIN retry failures, is 
presented to the contactless smart card reader/writer within a CD-determined 
period of time, the OBFTP will unblock the operator card and send the 
’Unblock Card Success' screen details to the DDU. The OBFTP displays the 
'Unblock Card Success' screen. Refer to the 'Unblock Operator Card' section 
in the screen-flow presentations in Appendix C for the proposed screens. The 
OBFTP then returns to the beginning of step 6) in this sequence. 


Exit Conditions 

Supervisor mode will be exited when: 

1. The <Logoff> hotkey message is received from the DDU, which causes the OBFTP to 
enter Out of Service/Logon mode. 

2. The Device Control hotkey message is received from the DDU, which causes the 
device to enter Device Control mode. 

Device Configuration Mode 

This section describes those actions that take place whenever an uninitialized device is 
being configured for usage. 

The following information is stored in the OBFTP active cradle: 

1. Device (OBFTP) I/P address 

2. DDU I/P address 

3. Bus network I/P address mask 

4. DAC I/P address 

5. DAC gateway I/P address 

6. Vehicle ID 
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7. Source Participant ID (i.e., the Agency owning the OBFTP) 

The first three items in the list above cannot be entered using the DDU as these are 
required to establish the connection to the DDU in the first place. These items are 
configured using the diagnostic PC and connection to the OBFTP. 

Note: In order to use the DDU to configure the other (not shaded) parameters, 
the DDU I/P address also needs to have been configured in the DDU first. 

[ Not e : Th e gat e way I/P addr e ss w ill chang e as m i grat i on from L I M to F I M i s 
mad e . For L I M th e gat e way w ill b e th e addr e ss of the on-board WLAN 
br i dg e , wh ile for F I M th e gat e way w ill b e chang e d to th e addr e ss of th e 
VLU through which th e OBFTP transf e rs w i l l tak e plac e . 


Note: The Source Participant is the Agency owning the OBFTP. In the case Commented [d27]: change orde 

where ST buses are operated by other agencies, e g.. KCM. KCM would 
be the source participant. ST is the Service Participant, i.e. the Agency 
indicated in usage data as owning the transactions. Note that the Service 
Participant comes from configuration data and is associated with the 
route/run in operation. 



Entry Conditions 

When an OBFTP has not been previously configured (i.e. it is an uninitialized device), it 
has only been partly configured, or it has been located on a different vehicle, the OBFTP 
will need to be set up to match the hardware in the vehicle. 

The OBFTP will complete Start-Up mode, and then progress immediately to Device 
Configuration mode. 

If the OBFTP has been previously configured, an operator card with the maintenance role 
enabled must be used to logon. Refer to section 3.10.3.17 for maintenance mode 
functions. 
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3.10.3.19.2 Sequence of Events 



During the Device Configuration mode sequence, the OBFTP will display one of the 
Configuring Device screens shown in Figure 28. Refer to the ‘OBFTP & DDU - Configure 
Device’ screens in the screen-flow presentations in Appendix C for the proposed screens. 

1. Device Configuration mode involves the following steps: 

a. Configuring the OBFTP cradle with the OBFTP I/P address, the DDU I/P address, 
and the bus network I/P address mask. This is performed with the diagnostic PC 
connected to the OBFTP (refer also to section 3.10.3.19). 
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b. Set the DAC I/P address 

c. Set the DAC Gateway I/P address 

d. Set Vehicle Number 

e. Set the participant ID 

Note: For CT buses, the vehicle ID will be read out of the TSP tag and updated 
into the cradle automatically at start-up/logon, so this “set” function is an 
initial, day 0, default value. 

[ Not e : Th e DAC Gat e way i n L I M mode w ill b e v i a th e WDOLS, wh il e i n F I M mod e 

th e gat e way w ill b e via th e VLU. 

2. The device configuration sequence is as follows: Commented [d28]: change orde 


a. The OBFTP sends the Device not Configured screen details to the DDU and the 
OBFTP. Refer to the ‘OBFTP & DDU - Device not Configured' screens in the 
screen-flow presentations in Appendix C for the proposed screens. 

i. When the <OK> hotkey message is received from the DDU, the OBFTP 
proceeds with the configuration. 

b. The OBFTP sends the Set DAC IP screen details to the DDU. Refer to the ‘DDU - 
Set DAC IP’ screen in the screen-flow presentations in Appendix C for the 
proposed screen. 

i. When the <OK> hotkey message is received from the DDU, the OBFTP 
proceeds with the configuration. 

ii. If the <Cancel> hotkey message is received from the DDU, or a configurable 
timeout occurs, the process starts from the beginning and the OBFTP sends 
the Device not Configured screen details to the DDU and the OBFTP. 

c. The OBFTP sends the Set Gateway IP screen details to the DDU. Refer to the 
‘DDU - Set Gateway IP’ screen in the screen-flow presentations in Appendix C for 
the proposed screen. 

i. When the <OK> hotkey message is received from the DDU, the OBFTP 
proceeds with the configuration. 

ii. If the <Cancel> hotkey message is received from the DDU, or a configurable 
timeout occurs, the process starts from the beginning and the OBFTP sends 
the Device not Configured screen details to the DDU and the OBFTP. 

d. The OBFTP sends the Set Vehicle ID screen details to the DDU. Refer to the 
‘DDU - Vehicle ID' screen in the screen-flow presentations in Appendix C for the 
proposed screen. 

i. When the <OK> hotkey message is received from the DDU, the OBFTP 
proceeds with the configuration. 

ii. If the <Cancel> hotkey message is received from the DDU, or a configurable 
timeout occurs, the process starts from the beginning and the OBFTP sends 
the Device not Configured screen details to the DDU and the OBFTP. 

e. The OBFTP sends the Set Participant ID screen details to the DDU. The 
maintenance personnel is prompted to input the Source Participant ID, for the 
device that is being configured. Refer to the ‘DDU - Set Participant ID’ screen in 
the screen-flow presentations in Appendix C for the proposed screen. 
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i. When the <OK> hotkey message is received from the DDU, the OBFTP writes 
the configuration information to the OBFTP cradle. 

ii. If the <Cancel> hotkey message is received from the DDU, or a configurable 
timeout occurs, the process starts from the beginning and the OBFTP sends 
the Device not Configured screen details to the DDU and the OBFTP. 

f. If writing the configuration parameters was unsuccessful, the OBFTP sends the 
Configuration Unsuccessful screen details to the DDU. Refer to the ‘DDU - 
Configuration Unsuccessful' screen in the screen-flow presentations in Appendix 
C for the proposed screen. 

i. If the <OK> hotkey message is received from the DDU or a configurable 
timeout occurs, the OBFTP configuration begins again at step a above, i.e. the 
OBFTP sends the Device not Configured screen details to the DDU and the 
OBFTP. 

g. If writing the configuration parameters was successful, the configuration process 
ends and the OBFTP moves to the appropriate mode. If you enter from startup 
mode you will move on to OOS/Logon mode while if you entered in maintenance 
mode you will return to maintenance mode. 


3.10.3.19.3 Exit Conditions 


1. On successful completion of Device Configuration mode, the OBFTP will progress to 
the appropriate mode. If you enter from startup mode you will move on to OOS/Logon 
mode while if you entered in maintenance mode you will return to maintenance mode. 
Refer to section 3.10.3.3 for details of the OOS/Logon mode or maintenance mode. 

2. If the Device Configuration mode is not completed, then the OBFTP sends the Device 
Not Configured screen details to the DDU. Refer to the ‘DDU - Device not Configured' 
screen in the screen-flow presentations in Appendix C for the proposed screen. 
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3.10.3.20 Shutdown Mode 



Figure 29: Shutdown Mode 

3.10.3.20.1 Entry Conditions 

The OBFTP will enter Shutdown mode when all of the following conditions are met: 

1. The OBFTP is in Out Of Service/Logon mode. 

2. The vehicle ignition switch is off. 

3. The OBFTP has been idle for greater than the CD-configurable time (Auto Power 
Down Timeout). 

During sustained power failure, the OBFTP will shut down while retaining transaction 
consistency between the card and the device while ensuring user safety. 







Security Level: 


Fare Transaction Processor (DR 
102B) - Functional Specification 


Central Puget Sound 

Regional Fare Coordination System 

3.10.3.20.2 Sequence of Events 



levice OF 

IJ 


Figure 30: Shutdown Mode Sequence of Events 
The following events will occur: 

1. The OBFTP will save all UD. 

2. The OBFTP will defragment its flash filing system. 

3. The OBFTP will turn off. 

3.10.3.20.3 Exit Conditions 

The OBFTP will exit Shutdown mode when it has completed all Shutdown mode 
operations and has switched itself off. 
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3.11 Card Types 

The OBFTP identifies and processes the card applications and roles listed in Table 11. 
The table also lists the applicable OBFTP modes in which the card applications and roles 
are accepted; outside of the modes listed, the cards are ignored. 


Table 11: Card Application/Role Matrix 



Note: Cards with applications (per Table 11) can also be produced as training 
cards, such as training customer cards or training operator cards. As 
described in section 3.10.3.16, a field on the smart cards is used to 
indicate that the applications and roles on the card can only be used for 
training purposes. Also, any UD generated is flagged as training data, and 
will not affect the revenue system. 


3.12 Business Processes 


3.12.1 General 

All business rules are processed according to SEA-00090 Business Architecture [3], 

The business processes supported are listed below: 

• Operator logon 

• Processing of cardholder fare payment transactions 

• Prohibiting a cardholder fare transaction if there is insufficient memory to store details 

• Storage of cardholder transaction details as usage UD 


3.12.2 Operator Logon 

The operator logon process is initiated from the DDU (refer to SEA-01048 Driver Display 
Unit (DR 103B) - Functional Specification [19]). However, it is the OBFTP that performs 
validation of the operator entered password against the password on the operator card or 
against the password stored in CD for manual logons. 
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Note that, in the absence of the OBFTP, the operator can still perform a manual logon at 
the DDU. However, the operator will be unable to perform fare collection activities without 
the OBFTP. Note also, that as part of OBFTP configuration data, each Agency can 
specify the logon method required, i.e. automatic (using an operator card and password), 
or manually (using an Operator ID and password). 

Operator automatic logon attempts are counted and restricted to a CD preconfigured 
count (default attempts = 3). Each logon attempt (manual or automatic) is logged, even if 
invalid IDs and/or passwords are entered. 

Note: Specific logon processing is provided for KCM to support default logons of 
the radio system when a specific number of automatic (card-based) logons 
fail. This functionality is implemented on the DDU, so it is not described 
here. 

Logon details are stored on the DDU and used for access to other on-board equipment 
and/or applications. Refer also to section 3.6.1 regarding security and DDU public data. 
The following details are either read from the operator card or are selected by the 
operator performing a manual logon, depending on the logon method: 

• Route Number 

• Run Number 

• Trip Number 

• Operator ID 

• Additional fields as required 

These details are checked against CD for validity and correlation with each other prior to 
the start of transaction processing. 

The complete logging on sequence and associated conditions are provided in section 
3.10.3.3. Refer also to the 'OBFTP & DDU - Logon’ screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

3.12.3 OBFTP Fare Processing 

The OBFTP processes cardholder fare payment transactions via the CSC interface. The 
fare to be paid is based on the default fare basis for the journey (for example two zones), 
according to the business rules as specified in SEA-00090 Business Architecture [3], 
Details of all fare processing functions are in section 3.10.3.9 covering On Trip mode, 
specifically in section 3.10.3.11.14 on fare processing. 


Fare Zone Preset 

Fare cards contain a field to indicate the cardholder's fare zone preset. This field is used 
to override the default fare basis for the journey without interaction by the cardholder or 
operator. The operator is still able to perform a manual override of the fare card default 
setting if requested by the cardholder (refer also to section 3.10.3.11.5). 


Ride-Free Area 

On almost all occasions fares are processed as the cardholder boards the vehicle. The 
exception is when the cardholder boards a vehicle inside the RFA (Ride-Free Area). 
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When the cardholder boards a vehicle inbound to an RFA, the fare card is presented for 
processing as the cardholder enters. When the cardholder boards a vehicle outbound 
from a RFA, the fare card is presented for processing as they leave. In the case of travel 
entirely within the RFA, the cardholder need not present the fare card, as travel is free. 
There are some exceptions to the fare payment rules in the RFA. 

Note: While the Ride-Free Area is only applicable between certain hours of the 
day, the OBFTP does not change the fareset to or from the RFA fareset as 
these time boundaries are reached. It is the responsibility of the operator 
to select the RFA fareset within the Ride-Free Area and an alternate 
fareset if outside the ride free area or outside the time of RFA operation. 
This functionality is as agreed during the DDU/OBFTP design finalization 
workshops. Refer to SEA-01516 DDU/OBFTP Design Finalization 
Workshop Notes - 2005-01-11 [43], Refer also to section 0, which covers 
selection of faresets. 

Note: The OBFTP is configured for single tag operation, and therefore it does 
not distinguish between tagging on entry or exit. Therefore, when transfer 
times from previous trips are checked, only the actual transaction times 
are checked which won't necessarily match with times when patrons 
boarded the vehicles in the RFA. For this reason, the transfer times need 
to allow this situation. 


3.12.3.3 Supported Payment Types 

The OBFTP supports payment of the fare by the cardholder by any of the following 
methods: 

• Electronic Fare (Purse) 

• Electronic Fare Discounts 

• Period Pass Fare 

• Multiride Fare 

• Transfers 

Note: The OBFTP will record underpayments; however, the collection of cash 
that may or may not cover the underpayments is the responsibility of the 
operator. 


3.12.3.4 


Personal Care Attendant (PCA) 

Certain concession fare cards will be configured to have their Personal Care Attendant 
(PCA) bit set. This identifies the cardholder as traveling with an attendant that does not 
have a fare card of their own. 

When a fare card with the PCA bit set is presented for fare payment, the OBFTP sends a 
message to the DDU to indicate this to the driver. Refer to the ‘DDU - Discount 
Transactions’ screens in the screen-flow presentations in Appendix C for the proposed 

Note: Policies covering personal care attendants, including any additional fare 
required to be paid, is up to each agency. No fare collection is processed 
for PCAs by the OBFTP, except if agency configured counters are used to 
record the associated ridership. 
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3.12.4 Audit Register Updating 

During OBFTP transactions, events, or any other auditable circumstances, the audit 
registers are updated. Audit registers maintain a count of system events pertinent to the 
operation of the OBFTP. These counters are maintained for the life of the device. 


3.12.5 Configuration Data (CD) 

The OBFTP will store two sets of CD locally: 

1. One active CD set for typical services 

2. One time-triggered changeover CD set for typical services 

Note: For some configuration data files it is not necessary to store current and 
future files as described above. For example, actionlist files, where the 
new file replaces the current file as it contains the latest information and is 
always ‘active’. 

CD sent by the Central System that the OBFTP requires can be divided into two (2) 

categories: 

1. Nonessential 

This includes application upgrade files and security keys, which will be included only 
when necessary. No action is taken if any files marked as Nonessential are missing 
because the OBFTP has default versions of nonessential CD as part of its application. 

2. Critical 


These files are required for In Service operation. The validity of these files is checked 
before going into In Service mode and then periodically, in order to be able to 
guarantee their validity. 

CD includes the following: 

a. Message content and format (text content, line positions, font size) for transaction 
states and events 

b. Audio signals that are triggered for different transaction states and events 

c. Status indicators for different transaction states and events 

d. Minimum, maximum and default volume for audio signals for the OBFTP 

e. Minimum, maximum and default contrast level for the OBFTP 

f. Minimum, maximum and default display backlight level for the OBFTP 

g. Fare tables . 

Note: Where an Agency operates routes for another Agency (as is the case for 
ST), fare tables will contain routes for both Agencies. 


3.12.6 Prohibit Transaction when Insufficient Memory 

If UD is not uploaded for a long period of time, the OBFTP memory may eventually 
become filled and become insufficient to store further UD. When this happens, the 
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OBFTP will enter Out Of Service/Memory Full mode and display the Memory Full 
message. 

If the OBFTP is in On Trip mode, the OBFTP will progress to End Shift mode. 

If the OBFTP is in On Shift mode the OBFTP will display the Out Of Service/CD/UD 
message and await connection to the DAC. 

The OBFTP will remain inoperable for fare transactions pending upload of UD. 

Refer also to the ‘OBFTP & DDU - OBFTP Memory Full’ screens in the screen-flow 
presentations in Appendix C for the proposed screens. 

3.12.7 Usage Data (UD) and Device Messages 

Significant occurrences in the OBFTP are handled in a number of ways: 


These are generated at run time, stored as usage data, and eventually uploaded to 
the DAC in bulk. The DAC then passes the data on to the Central System. If the 
upload fails, the usage data will be held indefinitely until the upload is successful. 
Events are typically generated for occurrences such as mode changes, 
communications faults, and device power-ups. They also include: 

a. Transaction data (only for successful transactions) 

b. Ridership counter data 

c. End of Shift reports 

d. Event record - data generated by the OBFTP to indicate: 

i. The operational status of the device, including alarms and alerts 

ii. Smart card and smart card product exceptions 

iii. Configuration data updates 

iv. Record of system maintenance activities 

v. Information defined to support KPI calculations (contractual and 
noncontractual) 

vi. Logon attempts (successful or otherwise) 


These are generated during fare payment and are normally associated with financial 
data. They are handled in the same way as events. 

3. Audit Registers 

These counters are incremented for significant occurrences. The data stored by the 
audit registers may be written to a UD record and handled in same way as events. 
Audit registers typically keep a count of occurrences such as device mode changes, 
read/write errors, transaction type totals, and cardholder concession group usage. 

The generation of all events, transactions and audit register UD can be independently 
disabled via a series of flags in CD. The OBFTP stores UD in a NVRAM-based buffer. 

The OBFTP stores the buffer to flash memory whenever the buffer is full or during its 
housekeeping operation. UD in flash is transmitted to the DAC. When acknowledgement 
of successful transmission of the UD arrives from the DAC, the flash is erased. 
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If acknowledgement does not arrive, the UD in flash memory is kept for another 
transmission attempt later. 

All data records will contain date/time and the device ESN, and they will not be deleted or 
overwritten until they have been uploaded. 

The OBFTP protects any transaction data in the event of power loss and power 
fluctuations. 


Table 12: Event Messages Generated by the OBFTP 



Table 13: Event Messages Received by the OBFTP 



Note: The ability to store a UD event for a UD memory full condition will depend 
on the threshold value configured in CD and on whether or not other 
asynchronous processes are generating UD at the same time. 
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4 


4.1 


4.2 


SEA-01050 
Revision ■ 


Quality Assurance (Duplicated in SEA-01049 
(DR 102 A)) 

General 

The OBFTP development includes the following stages of testing to ensure quality and 
compliance to requirements: 

• Article testing, to verify that the OBFTP requirements are met. 

• System testing, to verify that the OBFTP operates in the target system. 

• Field testing, to verify over time that the OBFTP operates in the target environment. 

Responsibility for Tests 

Testing is the responsibility of ERG, and it is described in SEA-01199 Overall Inspection 
and Test Plan (CDRL 23) [17]. 
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Appendix A Hardware Cross Reference Matrix 
(Duplicated in SEA-01049 (DR 102A)) 

This appendix is intentionally left blank. 
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Appendix C OBFTP Customer Display Screens 

This section outlines the suggested screen layouts for the OBFTP. All screen text and 
graphics are configurable. Audible tones and the LED indicators are also fully 
configurable. 

OBFTP LCD screen text, graphics, tones, LED indications, and message text are all 
configurable via CD using CD-configuration software. Different CD can be downloaded to 
different devices, allowing customization of the LCD screens for each Agency. Message 
sets and formats are to be approved by the Contract Administrator. 

Typical OBFTP screens are detailed for each Agency in the PowerPoint presentations 
attached in Table 15. Note that the presentations include flows for the OBFTP and the 
DDU, as they are closely related. 

The presentations reflect the screen detail and sequencing between screens, however 
due to limitations of the presentation, the fonts shown are an approximation of that 
achievable on the OBFTP. Similarly, the timing between screens has been set to facilitate 
viewing of the presentation; timing of screens on the OBFTP will be configurable in CD to 
suit patron interactions. 

Messages will be displayed in the largest font size possible, considering the number of 
characters to be displayed. 

Messages providing feedback to both valid and invalid transactions remain displayed until 
the cardholder smart card is removed from the smart card reader/writer module field. 

Once the cardholder smart card is removed from the smart card reader/writer module 
field, the display is updated to the next expected display. 


Table 15: OBFTP Screen Flow Presentations 


Embedded PowerPoint Presentation 

Description 

ffl B 

SEA-01314 KCM DDU SEA-01314 KCM DDU 
Operations ScreenfbOperations Screenfb' 

Typical DDU/OBFTP Screen Flow - KCM 

B B 

SEA-01305 CT DDU SEA-01305 CT DDU 
operations screen flo'operattons screen flo' 

Typical DDU/OBFTP Screen Flow-CT 

B B 

SEA-01317 PT DDU SEA-01317 PT DDU 
Operations ScreenfloOperations Screenflo' 

Typical DDU/OBFTP Screen Flow - PT 

B B 

SEA-01469 ET DDU SEA-01469 ET DDU 
Operations Screen FkOperations Screen Fk 

Typical DDU/OBFTP Screen Flow - ET 
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Embedded PowerPoint Presentation 

Description 

C] HP] 

SEA-01316 KT DDU SEA-01316 KTDDU 
Operations ScreenftoOperations Screenflo' 

Typical DDU/OBFTP Screen Flow - KT 


C.1 KCM DDU Operations Screens 
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C.2 CT DDU Operations Screens 
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C.3 PT DDU Operations Screens 
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C.4 ET DDU Operations Screens 
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C.5 KT DDU Operations Screens 
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Appendix D OBFTP Operator Screens 

The OBFTP Operator screens are included in the PowerPoint presentations listed in 
Table 15 in Appendix C. 

Note: The OBFTP Operator screens are sent to and appear on the DDU in the 
AFC window. Operator screens require the correct configuration of 
templates and hotkey assignments on the DDU to be correctly displayed 
and operated. Refer to SEA-01048 Driver Display Unit (DR 103B) - 
Functional Specification [19], 

The message sets proposed in the PowerPoint presentations in Table 15 are for review 
and comment, and they are subject to approval by the Contract Administrator. 
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Appendix E Adam 6510 Ethernet Hub (Duplicated in 
SEA-01049 (DR102A)) 

This appendix is intentionally left blank. 
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Appendix F Traceability (Duplicated in SEA-01049 
(DR 102 A)) 

Table 16: Requirements Traceability to Contract [1] 

Reference 

DR Section 

Comment 

6.ill-3.2.0a 

3.1 


6.lll-3.2.0b(i) 

3.10.3.3.4 


6.lll-3.2.0b(ii) 

3.10.3.3.3 


6.lll-3.2.0c(i) 


Fareset determined from CD and other logon 
information. 

6 

lll-3.2.0c(ii) 

3 

12.2 


6 

lll-3.2.0c(iii) 

3 

12.2 


6 

lll-3.2.0c(iv) 

3 

12.2 


6 

lll-3.2.0c(v) 

3 

12.2 


6 

lll-3.2.0c(vi) 

3 

12.2 


6 

lll-3.2.0e 

i) 

3 

2, 3.9.1.1 


6 

lll-3.2.0e 

i) 

3 

2, 3.9.1.1 


6 

lll-3.2.0e 

ii) 

3 

2 


6 

lll-3.2.0e 

ii) 

3 

2 


6 

lll-3.2.0e 

ill) 

3 

2 


6 

lll-3.2.0e 

iv) 

3 

2 


6 

lll-3.2.0e(v) 

3 

2 


6 

ill-3.2.Of 

3 

6.5, 3.12.7 


6 

lll-3.2.0g 

3 

9.1.1,3.9.1.2 


6 

111-3.2.Oh 

3 

6.3, 3.7,3.12.7 


6 

lll-3.2.0i 

3 

12.7 


6 

111-3.2.0] 

3 

12.5 


6 

lll-3.2.0j 

3 

12.5 


6 

lll-3.2.0j 

3 

12.5 


6 

111-3.2.0] 

3 

12.5 


6 

lll-3.2.0k 

3 

12.5 


6 

II 1-3.2.01 

3 

10.3.19 


6 

lil-3.2.1 -1a(i) 

2 

3.2.5.1 

See SEA-01049 (DR 102A) for section 2 refer 

6 

IM-3-2.1.1a(ii) 

2 

3.2.5.1 

See SEA-01049 (DR 102A) for section 2 refer 

6 

111-3.2.1.1 a(iii) 

2 

3.2.5.1 

See SEA-01049 (DR 102A) for section 2 refer 

6 

111-3.2.1.1 

a(iv) 

2 

3.2.5.1 

See SEA-01049 (DR 102A) for section 2 refer 
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Table 17 shows traceability between the non-Contract changes CCCA#3 RFIs/Requirements, Change 
Orders (COs), and Change Requests (CRs)) and this document. 


Table 17: Requirements Traceability to Phase II Requirements 


RFI/REQ Reference 

DR Section 

Comment 

RFCS RFI 236, EQP-003 

All sections of all screenflows 

DDU Display - Clock visibility 

IRFCSRFI 236, EQP-012 

3.10.3.4.2 

Manaaina data transfer 

RFCS RFI 236, EQP-051 


Error logging 

RFCS RFI 237, EQP-013 

Topic 3 in KCM screenflow 

KCM DDU - RTT key 

RFCS RFI 237, EQP-042 

Topic 2 in PT screenflow 

PT DDU - Pass icon 

RFCS RFI 237, EQP-043 

Topic 2 in PT screenflow 

PT DDU - Promotional and Bicycle icons 

RFCS RFI 237, EQP-044 

Topic 2 in PT screenflow 

PT DDU - Short Fare icon 

RFCS RFI 237, EQP-045 

Topic 4.4 in PT screenflow 

PT DDU - Multiple Fare Counter 

RFCS RFI 237, EQP-049 

Topics 2, 4.1,4.3 and 5 in PT 
screenflow 

PT DDU - ST icons 

RFCS RFI 238, EQP-025 

Topic 15 in KCM screenflow 

KCM DDU Volume Controls 

RFCS RFI 336, EQP-024 

Topic 18 in KCM screenflow, 
Topic 9 in CT screenflow, 

Topic 8 in KT screenflow, 

Topic 9 in PT screenflow, 

Topic 8 in ET screenflow 

DDU Messages - Revise messages 

RFCS RFI 336, EQP-030 

Topic 18 in KCM screenflow, 
Topic 9 in CT screenflow, 

Topic 8 in KT screenflow, 

Topic 9 in PT screenflow, 

Topic 8 in ET screenflow 

FTP Messages - Revise messages 

RFCS RFI 264, CDA-001 

3.10.3.16.2, Topic 48 in KCM 
screenflow, Topic 36 in CT 
screenflow, Topic 34 in KT 
screenflow, Topic 35 in PT 
screenflow, Topic 34 in ET 
screenflow 

DDU/OBFTP verification tool for the regional test bed 

RFCS RFI 266, CDA-004 

3.10.3.16.2, Topic 48 in KCM 
screenflow, Topic 36 in CT 
screenflow, Topic 34 in KT 
screenflow, Topic 35 in PT 
screenflow, Topic 34 in ET 
screenflow 

Testing specific dates in the RTB 


id [d30]: RH #236, SERM #1-001128, EQP-012 


SEA-01050-ERG Confidential ©ERG 2010- 

Revision 13.0/Feb 22, 2010 To be disclosed only to Agency personnel who 

have a need to know 


Page 2282 of 2283 


































Central Puget Sound Fare Transaction Processor (DR 

Regional Fare Coordination System Security Level 3 102B) - Functional Specification 


RFI/REQ Reference 

DR Section 

Comment 

Chanae Order |32| 

3.4.5, 3.10.3.3.5, 3.10.3.8, 



3.10.3.8.1J3.10.3.9, 

3.10.3.11.1^3.10.3.11.2* 
3.10.3.11.3J3.10.3.11 A 1 
3.10.3.11.4.1^3.10.3.11.4. 
3.10.3.11.10J3.10.3.12.1, 
3.10.3.12.2^3.10.3.15.1^ 

3.10.3.15.2 J3.10.3.19.1, 

3.10.3.19.2 
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